Wikibooks:Ich brauche Hilfe

Aus Wikibooks
Zur Navigation springen Zur Suche springen

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

Crystal Clear app wp.png
Abkürzung:
WB:IBH
Bitte beachten: Wikibookianer helfen gern – es geht hier aber ausschließlich um Wikibooks. Sonst gibt es Suchmaschinen oder die Wikipedia:Auskunft.
Nuvola apps filetypes.svg
Du hast Fragen über Wikibooks? Hier kannst du sie stellen.
  1. Schau vorher bitte auf FAQ oder im Wikibooks-Lehrbuch nach Antworten.
  2. Alle Mitarbeitenden sind freiwillig hier. Wenn deine Frage nicht sofort beantwortet wird, hab also bitte ein wenig Geduld.
  3. Was nicht hierher gehört, sondern wofür es eigene Seiten gibt:
  4. Wohin du deine Diskussionsbeiträge platzieren kannst, steht in Diskussionsseiten benutzen.
  5. Vielleicht ist deine Frage schon im Wikibooks-Lehrbuch beantwortet worden. Wenn nicht, setze sie bitte auch auf die Wunschliste für Hilfethemen

Bitte beachten:

  • aussagekräftigen Betreff wählen
  • Unterschreibe mit -- ~~~~.
  • Bei Fragen zu einem bestimmten Kapitel immer [[verlinken]]
  • Das neue Thema möglichst mit Abschnitt hinzufügen oben beginnen, oder den Link unterhalb dieses Abschnitts benutzen; dann wird die Überschrift automatisch zur Zusammenfassung, was den Abläufen hier hilft.
    Bei Fragestellung über die Bearbeiten-Funktion:
    • Neue Fragen bitte immer an das Ende des Textes setzen und mit einer neuen ==Überschrift== beginnen.
    • Wenn dir hier geholfen wurde, beende bitte das Thema mit {{erledigt|Dein Text-- ~~~~}}. Anstelle von „Dein Text“ kannst du schreiben, ob die Hilfe gut war und kannst dich auch bedanken.

Ältere Fragen finden sich in den Archiven:

Archiv-Übersicht über Wikibooks:Ich brauche Hilfe

2004 •  2005 •  2006 •  2007 •  2008 •  2009 •  2010 •  2011 •  2012 •  2013 •  2014 •  2015 •  2016 •  2017 •  2018 •  2019 •  2020 •  2021

Hinweise zur Archivierung: Themen werden archiviert, wenn sie abschließend behandelt wurden – entweder ausdrücklich oder implizit – oder wenn es seit mindestens 12 Monaten keine weitere Antwort gibt. Genutzt wird das Archiv des Jahres, in dem der letzte Beitrag veröffentlicht wurde. Ggf. wird für etwa drei Monate am Anfang im Abschnitt Kürzlich archivierte Themen noch darauf hingewiesen.

Archivierte Beiträge können in der Regel nur über das Stichwort, nicht über den Inhalt gesucht werden.

Wenn ein Thema nochmals besprochen werden soll, bitte hier als neue Frage stellen, ggf. mit einem Verweis auf die frühere Diskussion.

Für das Verfahren der Archivierung stehen Vorlage:Archiv Hilfe (mit Arbeitsanleitung) sowie Vorlage:Archiv Hinweis zur Verfügung.
Hilfe

Kürzlich archivierte Themen[Bearbeiten]

Letzte Archivierung durch Jürgen 18:30, 29. Dez. 2020 (CET)

Problem mit MediaWiki:Edittools[Bearbeiten]

Seit einiger Zeit wird die Liste der Sonderzeichen nicht mehr wunschgemäß angezeigt. Angeboten werden nur noch die Standard-Sonderzeichen (Umlaute bis </math>), aber nicht mehr die ComboBox zum Umschalten auf Wiki-Syntax, IPA und andere Sprachen. Die Auswahl z.B. der vorgefertigten Texte zur Wiki-Syntax ist also nicht möglich – nicht einmal <code>+</code>. Anders als ursprünglich vermutet liegt das nicht an meinen persönlichen Einstellungen; bei einem anderen Nutzer und bei Bearbeitung als IP besteht das Problem genauso.

Irgendetwas hat sich offensichtlich an der Zusammenarbeit mit MediaWiki:Onlyifediting.js und MediaWiki:Common.js geändert. Das Problem wurde bereits bei Wikipedia und den Verbesserungsvorschlägen angesprochen, aber nicht gelöst. Das Hauptproblem besteht darin, dass unsere Struktur der Helferlein ziemlich alt ist (siehe auch die Frage bei der Wikipedia). Eine korrekte Überarbeitung ist also ziemlich aufwändig.

Hat jemand eine Idee für eine schnelle Lösung?

Oder wäre provisorisch ein Ersatz ähnlich wie bei en-WB angebracht? Alles Wichtige (Standard-Sonderzeichen, Wiki-Syntax) wird im Bereich <p id="Standard">...</p> zusammengefasst und mit <br /> aufgeteilt.

Besser wäre natürlich eine dauerhafte Lösung. Aber wegen der Komplexität kann wohl nicht mit einer schnellen Erledigung gerechnet werden. -- Jürgen 11:32, 24. Okt. 2015 (CEST)

Erklärung dafür gefunden, dass die ComboBox nicht mehr angeboten wird: Laut WP:Technik ist die Funktion document.write() seit 6. Aug. 2015 nicht mehr verfügbar mit der entsprechenden Auswirkung. Der Versuch mit mw.loader.load durch diese Änderung hatte allerdings nichts gebracht; dazu wäre wohl mehr Anpassung erforderlich. -- Jürgen 12:23, 24. Okt. 2015 (CEST)

Als Notlösung füge ich erst einmal code ein; aber das reicht nicht auf Dauer. -- Jürgen 11:48, 7. Nov. 2015 (CET)

Hinweis: Eingabeprobleme wurden auch bei den Verbesserungsvorschlägen in mehreren Abschnitten angesprochen. Lösungen wurden angekündigt, aber nur teilweise umgesetzt. Diese Probleme sind so wichtig, dass sie möglichst erst nach einer vollständigen Lösung archiviert werden sollten. -- Jürgen 09:50, 31. Jan. 2016 (CET)

Wie lange bleibt das Score-Pluggin deaktiviert?[Bearbeiten]

Leider finde ich nirgends ein Link dazu, warum und für wie lange das Score-Plugin für Musiknoten deaktiviert ist. Kann mir einer mit einem Fingerzeig, wo der betreffende Beitrag steht, aushelfen? --mjchael 12:14, 24. Okt. 2020 (CEST)

Hallo Michael. Ich finde nichts, weder hier noch hier. Vielleicht hat es damit zu tun? In der Extension Score Seite sehe ich allerdings sowohl Stellen, wo score noch funktioniert, als auch wo es nicht funktioniert... LG Yomomo 20:35, 24. Okt. 2020 (CEST)
Was ist denn die Extension Score Seite? Und was ist genau gemeint? Hier z. B. wird bei mir alles tutti angezeigt: Musiklehre:_Freeware_für_Musiker#ABC-Editoren. Hab jetzt aber nicht weiter gesucht, sondern einfach nur nach einem score-Beispiel, um zu sehen, worum es geht. Falls es ein Ansatz ist: In Spezial:Version steht ein Update am 17.10.20, da scheint jemand den Code aufgeräumt zu haben (Details gibts beim Klick auf die Nummer). Könnte das einen Zusammenhang haben? Gruß --HirnSpuk 01:11, 25. Okt. 2020 (CEST)
Ich habe beispielsweise hier neue Noten eingregeben Musiklehre: Tonleitern (erste Kapitel). Bei schon geränderten Notenbeispielen bleiben die Bilder erhalten. --mjchael 10:12, 25. Okt. 2020 (CET)
Danke hirnspuk für den Hinweis. Die extensions Seite ist in meinem ersten Link oben in diesem Absatz, also hier: https://www.mediawiki.org/wiki/Extension:Score. Ich hab jetzt reedy@wikimedia.org kontaktiert (er hat die Version geändert, siehe hier) und warte auf eine Antwort. LG Yomomo 08:37, 25. Okt. 2020 (CET)
Merci! --mjchael 10:12, 25. Okt. 2020 (CET)
Ich hab was gefunden: w:en:Help_talk:Score#Error_message. Da wird verwiesen auf: phab:T257066. Anscheinend handelt es sich um ein Sicherheitsproblem mit dem Plugin. Alte Renderings werden angezeigt, Änderungen und Neue Sachen nicht. Ich hab die Diskussion nicht gelesen im Phabricator, aber da scheint eine Menge im Gange zu sein. Um zur Ursprungsfrage zurück zu kommen: einen Zeitplan scheint es nicht zu geben, daher ist die Frage an Reedy wahrscheinlich der richtige Weg? @Yomomo, wo auf der Seite sieht man denn, wo es funktioniert und wo nicht? Gruß --HirnSpuk 16:58, 25. Okt. 2020 (CET)

Eben. Hier ist auch die Antwort:

Hello George,

Unfortunately, yes this is intentional. There's been numerous fairly major security issues with the underlying programs that score uses. See https://phabricator.wikimedia.org/T257066

No timeline as of yet as to when this might be re-enabled fully

Thanks

-reedy

Also, keine Ahnung, wann es wieder funktionieren wird... Sorry... Ich hab auch kein Muster entdeckt (z.B. mit oder ohne Parameter), um zu erklären, warum es manchmal funktioniert und manchmal nicht. LG! Yomomo 20:46, 25. Okt. 2020 (CET)

Ping@mjchael, aktueller Status per obiger Links:

Viele Grüße, HirnSpukDisk – 03:52, 18. Jun. 2021 (CEST)

Ping@mjchael, aktueller Status:

  • So wie es aussieht, wird das Plugin wohl demnächst wieder aktiviert, vgl. Phab:T257066#7202898
  • Kurzfassung des Kommentars dort: "Reaktivierung von "Score" auf test.wikipedia.org zum test. Reaktivierung auf freiwilligen kleineren Wikis zum Test (Anm.: ich denke nicht, dass wir dafür in Frage kommen). Nach ~4 Wochen Reaktivierung auf allen Wikis mit Ausnahme von Hochsicherheits-Risiko-Wikis wie z. B. loginwiki (Anm.: Wenn mich jemand erhellen mag, was das ist, nur zu.)."

Viele Grüße, HirnSpukDisk – 09:21, 12. Jul. 2021 (CEST)

Ping@HirnSpuk, Das lässt hoffen. Doch ich glaub's erst, wenn es soweit ist. Danke für den Hinweis! mjchael 20:07, 12. Jul. 2021 (CEST)

Vorlage Farbverlauf[Bearbeiten]

Zwar bin ich eine nicht ganz doofe Inkscape-Benutzerin, bei der Wiki-Formatierung oft irgendwie aber immer noch Anfängerin. In meiner Inkscape:Vorlage:Navigationsleiste Handbuch würde ich das Babyrosa gern durch etwas Flotteres – konkret: einen linearen Farbverlauf (Gradient) – ersetzen. Die englische WP hat für so etwas eine Vorlage [1]. Könnte jemand von den Kollegen eine entsprechende Vorlage auch für uns schreiben oder mir (ersatzweise) einen Tipp geben, wie ich in meine Vorlage auf anderem Wege einen Farbverlauf hineinzaubern könnte? Auch über direktes Hinschreiben in die Seite wäre ich nicht böse (die Farben korrigieren kann ich später selber). Dank vorab und Gruß, --Stilfehler 19:32, 3. Nov. 2020 (CET)

Hallo @Stilfehler, der sinnvollste Weg ist der Import der von dir genannten Vorlage Template:Linear-gradient. Allerdings kann ich nicht abschätzen, was dabei zusätzlich zu beachten ist, nämlich die Technical Notes in der Beschreibung. @Stephan Kulla: Du hast erheblich mehr Kenntnisse über CSS als ich. Kannst du anhand des Quelltextes der englischen Vorlage beurteilen, ob der Import problematisch ist? Danke! -- Jürgen 20:10, 3. Nov. 2020 (CET)

Schau dir das Ergebnis an. Ich glaube, dass das ist, was du gemeint hast :-). Ich glaube allerdings nicht, dass für so was eine Vorlage notwendig ist, Copy-Paste sollte ausreichen :-). Falls du das willst, könnte ich auch eine Vorlage dafür schreiben (ist mir lieber als Import, da muss man einiges importieren), wenn niemand etwas dagegen hat... LG! Yomomo 20:25, 3. Nov. 2020 (CET)
Klasse, das ist genau das, was ich im Sinn hatte, vielen Dank! Ich hatte keine Ahnung, dass das so wenig Code braucht. Eine Vorlage Farbverlauf ist insofern meinetwegen gar nicht mehr nötig. --Stilfehler 20:39, 3. Nov. 2020 (CET)
(Allerdings: Super Dank für den Hinweis, man kann ja den Hintergrund für eine ganze Seite so ändern. Yomomo 21:06, 3. Nov. 2020 (CET)

Hallo Stilfehler und Yomomo, ein weiterer Hinweis, falls Ihr gestattet; wenn Du mehr wissen möchtest, wie das funktioniert, liest Du dort: https://developer.mozilla.org/de/docs/Web/CSS/linear-gradient. Wenn ich es richtig sehe, funktioniert es in einigen Browsern nicht, so wie es im Moment eingestellt ist, da wird dann einfach ein weißer Hintergrund angezeigt (kannst Du testen indem Du die Seite auf einem Smartphone im Standardbrowser anschaust). Dafür müsstest Du wohl schreiben: background-color: Bisque; background-image: -webkit-linear-gradient(left, #ffdddd, #ddddff); background-image: -moz-linear-gradient(left, #ffdddd, #ddddff); background-image: -o-linear-gradient(left, #ffdddd, #ddddff); background-image: linear-gradient(left, #ffdddd, #ddddff);. Das sind fünf Punkte, durch Semikola getrennt. Die erste Option sorgt dafür, dass Browser, die keine Farbverläufe können, die alte Farbe anzeigen (kannst Du ja gegen eine andere ersetzen), die anderen Optionen sorgen für die korrekte Darstellung in anderen Browsern als Firefox. Das ganze habe ich dem Link entnommen und das ist vorbehaltlich Stephans Expertenmeinung. Gruß --HirnSpuk 21:09, 3. Nov. 2020 (CET)

Super Hinweis! Danke Hirnspuk! Yomomo 22:53, 3. Nov. 2020 (CET)
Locked.svg

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

Vorlage Randnummern[Bearbeiten]

Moin!

In unseren Buchprojekten würden wir gerne Randnummern in jedem Kapitel (auf jeder Wiki-Seite) einführen, um die Werke in der Wissenschaft zitierbar zu machen. Gibt es dafür eine Vorlage? Ich konnte keine finden. Habt ihr einen Tipp, wo ich mich einlesen könnte, um eine solche Vorlage zu erstellen?

Danke und viele Grüße --OpenRewi 10:58, 13. Nov. 2020 (CET)

Dein Infobox-Vorlage kannst in jeder Seite einbetten mit {{:Benutzer:OpenRewi/_OpenRewi-Vorlagen/_Infobox-Hintergrund}}

In deinem Infobox kannst du eine "Variable" definieren mit {{{RN|0}}} (RN steht dann für RandNummer, 0 wird der Standardwert sein, wenn du keinen willst, schreibst du einfach: {{{RN}}}. Du kannst in deinem Infobox (im Arbeitsfeld mit Code) entscheiden, wo das erscheint und wie es aussieht. Siehe z.B. hier

Wenn du dann die Vorlage irgendwo einbettest, schreibst du einen Wert für die Variable, z.B.: {{:Benutzer:OpenRewi/_OpenRewi-Vorlagen/_Infobox-Hintergrund|RN=443}}

LG! Yomomo 11:39, 13. Nov. 2020 (CET)

Danke! Ich habe mich unklar ausgedrückt, sorry. Es geht mir nicht um eine Randnummer auf einer Seite, sondern um fortlaufende Randnummern für jeden Absatz, die Dank der Vorlage (z.B. bei Einfügungen) nicht jedes mal händisch verändert werden müssen. Als Vorbild dient uns hier Nikolas Buch, Verwaltungsrecht_in_der_Klausur/_§_5_Die_allgemeine_Leistungsklage/A._Die_Statthaftigkeit_der_allgemeinen_Leistungsklage, siehe z.B. die fett gedruckten Randnummern am Beginn jedes Absatzes. Oder habe ich dich falsch verstanden? --OpenRewi 11:48, 13. Nov. 2020 (CET)

Moin, in dem Beispiel von Nikolas wurde das händisch gemacht. Eine Vorlagenprogrammierung würde, so mein Eindruck, extrem aufwändig (in Betrieb, Nutzung und Wartung). Was man zum Beispiel machen könnte, wäre eine Vorlage nach dem Motto {{RN|Text 1|..|Text N}}, in der Vorlage wird dann die Formatierung der Absätze händisch in HTML vorgenommen. Probleme:

  • Die Vorlagengröße, weil man beliebig viele Einträge vorsehen müsste
  • Eine begrenzte Einbindungsgröße auf Wikiseiten (spontan weiß ich nicht, ob das hier ein Problem wäre)
  • Die Bearbeiter*innen müssten sehr streng darauf achten, wie sie den Text formatieren, ob das im VisEd überhaupt ginge, kann ich jetzt gar nicht sagen.

Es gibt hier Leute, die sehr viel Ahnung im Vorlagenprogrammieren haben, vielleicht wissen die noch eine Lösung. Eine Vorlage, die man am Beginn der Seite einbindet, man kümmert sich nicht weiter drum und dann läuft das, ist meiner Interpretation nach nicht möglich.

Es gibt für die Mediawikis die Skriptsprache LUA. Möglicherweise könnte man das damit realisieren. Nur Stephan hat LUA, soweit ich weiß, schon gemacht.

Eine sehr einfache Möglichkeit wäre eine nummerierte Liste zu benutzen:

Was man schreibt

==Abschnitt 1==

#{{Blindtext}}

#{{Blindtext}}

==Abschnitt 2==

#{{Blindtext}}

#{{Blindtext}}

Wie es aussieht

Abschnitt 1
  1. Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
  2. Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Abschnitt 2
  1. Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
  2. Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Nachteile:

  • Es dürften keine Leerzeilen mehr zwischen Absätzen stehen.
  • Die Absätze werden pro Abschnitt nummeriert.
  • Eine Listennutzung im Text würde komplexer.

Wenn es Euch lediglich um die Formatierung/Darstellung geht, und die Nutzung eine Vorlage pro Absatz Euch nicht schreckt. dann halte ich eine Vorlagennutzung für sinnvoll.

Denkt außerdem daran: Im Verlaufe der Zeit ändern sich Wikitexte, ein Zitat erfolgt also über einen Permanentlink. Was spricht dagegen Abschnitte und Absätze zu referenzieren? Das ist, soweit ich weiß, keine in Rechtsthemen übliche Zitierweise, aber akademisch durchaus üblich.

Achso, und zur eigentlichen Frage :-): mw:help:templates ist ein Startpunkt zum lesen. Sowie hier: Hilfe:Vorlagen/ Erstellen

Viele Grüße --HirnSpuk 12:53, 13. Nov. 2020 (CET)

Ich merke schon, dass das keine einfache Angelegenheit wird. Vielleicht lassen wir die Randnummern auch vorläufig weg und überlegen uns wie von Dir vorgeschlagen eine andere Zitationsweise. Danke jedenfalls für die Hinweise! --OpenRewi 14:06, 13. Nov. 2020 (CET)

Für den Titel: sei es OpenReWi/ Kap 1/ UKap 1

kannst du z.B. in der Vorlage OpenReWi/ Vorlage, folgendes hinzufügen:

{{DISPLAYTITLE:& {{#titleparts:{{PAGENAME}}|1|2}}<br>{{{X}}} {{#titleparts:{{PAGENAME}}|1|3}} }}

Dann in der Seite OpenReWi/ Kap 1/ UKap 1 folgendes hinzufügen:

{{:OpenReWi/ Vorlage|X=A}}

Dann wird in der Seite OpenReWi/ Kap 1/ UKap 1 als Titel folgendes vorkommen:

& Kap 1
A UKap 1

Du kannst auch das Aussehen in der Vorlage programmieren...

Für die Unterkapitel:

Normal die Unterkapitel mit == == Anfangen, wie in der Seite von Verwaltungsrecht

Für die Zahlen links kannst du dann folgendes benutzen:

<ol>
<li value="Zahl">ABSATZ</li>
<li> Nächste ABSATZ</li>
<li> </li>
.
.
</ol>

So wird die erste Zahl "Zahl" sein und ab diesem Punkt durchnummeriert. Ist sicherlich weniger Arbeit, als alles händisch zu machen...

Mit ol kannst du den Typ auch definieren. <ol type="a" So wird alles mit kleinen Buchstaben durchnummeriert usw. Das als Vorgeschmack. Also, es gibt schon einige Möglichkeiten...

LG! Yomomo 18:24, 13. Nov. 2020 (CET)

Moin OpenRewi, wenn Ihr mit der Verwendung von zwei Vorlagen pro Seite und einer Vorlage pro Absatz leben könnt und es nicht schlimm ist, dass die Absätze im Html als Liste formatiert sind, hätte ich womöglich eine Möglichkeit gefunden, sowohl die Überschriften, als auch die Absätze automatisch zu nummerieren (im Quelltext stehen die Vorlagen noch nicht, nur als Beweis, dass es wohl gehen wird):

Beispiel entfernt, um Seitenintegrität wieder herzustellen. Versuch mit mw:help:TemplateStyles. Einsehbar über Vorlage:Spielwiesenvorlage/styles.css (Stand vor 12:08, 23. Nov. 2020 (CET)), und Spezial:Permanentlink/937754#Vorlage_Randnummern. --HirnSpuk 12:08, 23. Nov. 2020 (CET)

Viele Grüße --HirnSpuk 17:51, 19. Nov. 2020 (CET)

Moin HirnSpuk, das sieht gut aus, vielen Dank für die Mühe! Allerdings wären mir das für den Anfang zu viele Vorlagen, zu viel Code. Unsere Autor:innen könnten dann nicht über den visuellen Editor arbeiten, was ich für die Zugänglichkeit wichtig finde. LG --OpenRewi 21:34, 22. Nov. 2020 (CET)

Fehlfunktionen durch neues Design[Bearbeiten]

Moin, habe meine Oberfläche, wie dort: Wikibooks:Verbesserungsvorschläge#Visueller_Editor_+_MediaWiki_neues_Design beschrieben auf das neue Design umgestellt. Dort sagte ich bereits, dass wir mal schauen müssen, welche Seiten dann Schwierigkeiten machen. Dieser Abschnitt hat den Sinn eine Liste bekannter Problemseiten zu sammeln. Da davon auszugehen ist, dass sich das Design noch verändern wird, kann man wohl auch davon ausgehen, dass sich das ein oder andere Problem vielleicht von selbst löst. Dennoch sollten wir frühzeitig beginnen dafür sensibilisiert zu sein und ggf. auch Feedback zum neuen Design zu liefern. Hiermit starte ich mal eine Liste bekannter Probleme, weil ich zufällig darüber stolperte. Gruß --HirnSpuk 17:59, 17. Nov. 2020 (CET)

Seiten mit Fehlfunktionen durch neues Vector-Design
  • Grundsätzlich tauchen gelegentlich 2 vertikale Scrollbalken auf, --HirnSpuk 17:59, 17. Nov. 2020 (CET)
    • bereits auf Mediawiki in die Diskussion eingetragen. Dagegen können wir wohl nichts tun. --HirnSpuk 17:59, 17. Nov. 2020 (CET)
Locked.svg

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

Ergebnis: Wenn es jemandem wieder auffällt bitte diesen Block entsprechend entfernen Viele Grüße, HirnSpukDisk – 04:02, 18. Jun. 2021 (CEST)

  • Die_Rennmaus/_Navi, --HirnSpuk 17:59, 17. Nov. 2020 (CET)
    • sieht komisch aus (scheinbar ein Ergebnis von Divitis und <br />, grundsätzliches Problem), geht über Vorlagen Klappbox und Kasten evtl. eleganter.
    • die Einbindung der Navigation in die Buchseiten führt zum Herausfallen aus dem eigentlichen "inhalt". Damit werden Punkte in der Navigation nicht mehr klickbar.
      Stand 00:06, 18. Dez. 2020 (CET), scheint jetzt zu funktionieren (gut genug?) --HirnSpuk 00:06, 18. Dez. 2020 (CET)
Locked.svg

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

Ergebnis: ?

  • In Druckversionen von Büchern taucht das Seitenmenü im Druck auf. --HirnSpuk 12:30, 23. Nov. 2020 (CET)
    Hab ich auch mal gemeldet, da mir noch ein Druckfehler aufgefallen ist. Ich glaube aber nicht, dass wir daran etwas tun können. --HirnSpuk 00:06, 18. Dez. 2020 (CET)
Locked.svg

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

Ergebnis: Wenn es jemandem wieder auffällt bitte diesen Block entsprechend entfernen Viele Grüße, HirnSpukDisk – 04:02, 18. Jun. 2021 (CEST)

  • Die Einbindung von einigen Seiten wird nicht sauber dargestellt (Vgl. z. B. Vorlage:Unterseiten) Viele Grüße, HirnSpukDisk – 04:02, 18. Jun. 2021 (CEST)


Stand 04:02, 18. Jun. 2021 (CEST): Teilweise scheinen die oben aufgezählten Probleme gelöst. Dennoch erhalte ich diese Liste, da uns noch das ein oder andere "blüht" (ja ich formuliere das bewusst so :)).

Ich arbeite seit Wochen ausschließlich im neuen Design und es gefällt mir bisher ganz gut. Viele Grüße, HirnSpukDisk

Import einer Versionsgeschichte[Bearbeiten]

Ich möchte die Seite Inkscape/ Button in ihrer Version von 2011 (ersatzweise in der aktuellen Version) samt Versionsgeschichte nach Inkscape/ Button (SVG-Editor) verschoben haben. Die aktuelle Seite Inkscape/ Button soll so erhalten bleiben, wie sie ist. Kann mir dabei jemand helfen? --Stilfehler 17:27, 16. Dez. 2020 (CET)

Ich bin mir ziemlich sicher, dass es recht einfach geht. Ich möchte aber noch etwas nachdenken, was bei diesen Wünschen am sinnvollsten ist, und bitte um ein paar Tage Geduld. -- Jürgen 17:59, 16. Dez. 2020 (CET)

Danke für die schnelle Rückmeldung. Die Sache hat keine Eile, ich wollte nur nicht auf eigene Faust vorgehen und die Versionsgeschichte dabei vernichten. Wenn die Operation hier im Projekt praktisch nie gebraucht wird, könnte ich leicht auch einen Plan B entwickeln, bei dem ein Versionsgeschichtenimport gar nicht erst nötig wird. Gruß, --Stilfehler 19:12, 16. Dez. 2020 (CET)
  1. Durch "normale" Administratoren:
    1. Inkscape/ Button kurz löschen
    2. Inkscape/ Button (nur die gewünschten Versionen) wiederherstellen
    3. Inkscape/ Button nach Inkscape/ Button (SVG-Editor) verschieben (ohne WL)
    4. Inkscape/ Button erneut wiederherstellen (mit allen Versionen)
  2. Oder durch Importeure (es gibt keinen in de.wikibooks) mit dem Recht importupload:
    1. Inkscape/ Button exportieren als XML (mit vollständiger Versionsgeschichte)
    2. XML auf die gewünschten Versionen reduzieren
    3. XML als Inkscape/ Button (SVG-Editor) wieder importieren
-- Reise Reise 20:46, 16. Dez. 2020 (CET)
Klasse, vielen Dank! Da ich keine Adminrechte habe, würde ich mich sehr freuen, wenn das jemand gelegentlich für mich tun würde. --Stilfehler 20:52, 16. Dez. 2020 (CET)

Variante 2 von Reise Reise funktioniert auch deshalb nicht, weil diese Art des Imports bei de-WB nicht aktiviert wurde. – mw:Extension:Duplicator könnte eine Lösung sein; im Jahre 2015 wurde über die Installation von "Duplicator" diskutiert, aber deren Notwendigkeit nicht ausreichend begründet und als (damalige) Beta-Version bei WMF als nicht geeignet angesehen.

Im ersten Anlauf meiner Überlegungen hatte ich gedacht, dass die jetzt gewünschte Version von Inkscape/ Button ausschließlich auf Stilfehler zurückgehen würde und die Versionsgeschichte (d.h. die anderen Autor:innen) unwichtig wären. Tatsächlich behält sie den Inhalt weitgehend unverändert, also ist es korrekt, dass die Entstehung der Seite nachvollzogen werden kann.

Fazit: Variante 1 von Reise Reise ist das richtige Verfahren. Ich kümmere mich (spätestens bis zum Jahreswechsel) darum; das ist eine Tätigkeit, die man als zeitlichen Lückenfüller erledigen kann. -- Gruß Jürgen

Moin, ich würde mich freuen, wenn dieses Verfahren dokumentiert und auf Wunsch auch angewendet werden könnte. Ich hätte in den letzten Jahren auch gelegentlich Bedarf gehabt. Danke und Gruß --HirnSpuk 01:45, 19. Dez. 2020 (CET)

Klappt leider nicht wie gewünscht. Das hatte ich befürchtet (allerdings konnte ich es nicht vorher prüfen und habe deshalb nicht gewarnt): Jede Seite (Kapitel) und jede Version haben jeweils eine eigene ID. Durch das Verschieben gehören die alten Versionen eindeutig zu der verschobenen Seite; zu der aktuellen (erweiterten) Seite gehören nur die neueren Versionen. Ich muss dich, Stilfehler, deshalb bitten, auf irgendeine Weise den Zusammenhang der beiden Seiten und ihrer Autor:innen deutlich zu machen. Ich empfehle eine kurze Erläuterung auf beiden Diskussionsseiten mit entsprechenden Verweisen; auf der Disk. zur aktuellen Button-Seite sollte (als Ersatz für Versionsgeschichte und Autorenliste) ein Permanentlink auf die Version von 2011 hinweisen.

@Reise Reise und @HirnSpuk Nach Lage der Dinge bringt es vermutlich nichts, dieses Verfahren zu beschreiben. Wenn du (HirnSpuk) eine passende Hilfe-Seite heraussuchst, bin ich trotzdem zu einem Hinweis bereit. -- Jürgen 16:01, 25. Dez. 2020 (CET)

Können wir nicht einfach einen Importeur bestimmen (oder alle Admins dazu machen)? Dann kann einfach eine XML eingelesen werden. Ich konnte leider nicht herausbekommen, wie man dieses Recht setzt. Für den Fall, dass es hier hilft: m:Terms_of_use/de#7c (Eine Autorennennung in der Zusammenfassungszeile wird als angemessen betrachtet, was in diesem Fall sicher angemessener ist, als eine Liste auf der Diskussionsseite). Ein Hinweis macht sich sicherlich gut auf Hilfe:Import. Gruß --HirnSpuk 00:08, 26. Dez. 2020 (CET)

Da die Versionsgeschichte in der neuen Seite vorhanden ist, scheint es ja doch irgendwie geklappt zu haben. Herzlichen Dank für das Weihnachtsgeschenk! --Stilfehler 17:53, 27. Dez. 2020 (CET)

Hallo Stilfehler, die Versionsgeschichte der alten Version ist aber verloren gegangen, wenn ich das richtig gesehen habe. Ich glaube das meinte Jürgen mit seiner Bitte. Gruß --HirnSpuk 18:17, 27. Dez. 2020 (CET)

Ich verstehe. Danke für den Hinweis, ich werde das heute umzusetzen versuchen. Gruß, --Stilfehler 18:52, 27. Dez. 2020 (CET)

Interne Links, die in exportierten Dokumenten funktionieren[Bearbeiten]

Moin,

bei OpenRewi erstellen wir als wissenschaftliche Mitarbeiter unsere Texte bei Wikibooks, wollen diese aber auf jeden Fall auch in einem Verlag veröffentlichen. Bei der gängigen Verlagspraxis bedeutet das leider einen Export in odt/docx. Wenn das passiert, werden die internen Links nutzlos, was sehr viel Arbeit nach sich zieht. Uns kam deshalb die Idee, einfach "externe" https-Links zu benutzen. Das hätte gleichzeitig den Vorteil, dass in einem Ebook/PDF sofort wieder auf Wikibooks verwiesen wird, was uns ganz recht ist, weil wir mit den Leser:innen ins Gespräch kommen möchten.

Soweit ich das bis jetzt überblicken kann, wären die Nachteile, dass die Links anders dargestellt werden (was uns nicht stört) und sich Links auf die jeweilige Seite (Werkzeug) nicht anzeigen lassen. Gäbe es sonstige Bedenken?

Beste Grüße, Max --OpenRewi 16:56, 17. Dez. 2020 (CET)

Du könntest ja auch noprint und includeonly benutzen (oder war es onlyinclude?). Dann kannst du beides haben... Beispiel (siehe sourcecode): Yomomo 20:51, 17. Dez. 2020 (CET)
Am Besten macht ihr eine kleine Vorlage: <div noprint>[[{{{1}}}]]</div><includeonly>https://de.wikibooks.org/wiki/{{{1}}}, oder so ähnlich, wo 1 die wikibooks Adresse, z.B. "Hauptseite". Yomomo 23:15, 17. Dez. 2020 (CET)

Die Idee finde ich ziemlich schick. Das Problem ist, dass sie nicht praktikabel ist, oder übersehe ich was? Die include-Tags sorgen doch nur für Mediawiki-interne Transklusionssteuerung? Welchen Vorteil hätte das für die Druckversion?

Die Vorlage jedoch ermöglicht vielleicht ein Parsing über den Export, sodass die Links für die Druckversion (und so auch das Ebook?) anders geparst werden könnten?

Mir sind aber bisher keine Bedenken eingefallen. --HirnSpuk 00:09, 18. Dez. 2020 (CET)

Die Vorlage (falls sie klappt), würde dafür sorgen, dass in der Seite nur die Interne Links sichtbar sind (möglicherweise mit einer zweiten Parameter für den Namen des internen Links) und in der Druckversion nur die https Version des Links. Includeonly macht den beinhalteten Teil NUR in der aktuelle Seite unsichtbar, noinclude NUR wenn die Seite eingebettet wird. Also, wenn das als Vorlage klappt, sieht man in der aktuellen Seite nur den internen Link, der dann nicht in der Printversion auftaucht, stattdessen sieht man im Druck die https Adresse. Etwas vollständiger wäre es so: <div class="noprint">[[{{{1}}}{{#if{{{2|}}}|{{!}}{{{2}}}}}]]</div><includeonly><noinclude>https://de.wikibooks.org/wiki/{{{1}}}</noinclude></includeonly> Yomomo 10:02, 18. Dez. 2020 (CET)

Etwas in der Art sollte angemessen sein. Bei Wikijunior Europa (Beispiel Belgien) habe ich Flagge und Lage in zwei Varianten eingebaut: für den Export mit <includeonly>als Tabelle nebeneinander, für die direkte Anzeige mit <noinclude> an zwei Stellen untereinander. (Deswegen konnte ich nicht mit einer Vorlage arbeiten.) Ich weiß aber nicht (mehr), wie man am besten die exportierte Version erkennen kann – also ausprobieren! – Zusatzhinweis: Bei der Version mit der vollständigen URL müssen u.U. Leerzeichen und Umlaute codiert werden; dafür gibt es Parser-Funktionen, die in die Vorlage eingebaut werden können. -- Jürgen 10:07, 18. Dez. 2020 (CET)

Das ist ein toller Vorschlag und wenn ich das Buch alleine schreiben würde, würde ich es wahrscheinlich so machen. Im Sinne der Einfachheit für unsere Autoren würde ich dennoch die https-Variante benutzen, gerade weil sie sich so einfach erklären lässt. Viele Grüße, Max --OpenRewi 20:17, 18. Dez. 2020 (CET)

Was ist dann so kompliziert, wenn die Autoren (beispielsweise) so was schreiben sollen? {{NoprintLink|Name der Seite}} Weil das ist, was sie dann schreiben sollten, sobald die Vorlage fertig ist. Ich finde diese Variante viel einfacher für neue Autoren und sie hat auch den Vorteil, dass in der aktuellen Seite der Link einfach dargestellt wird und in der Druck Version mit https... Oder? Und noch dazu: Falls du später doch deine Meinung änderst, ist es viel einfacher EINE Vorlage zu ändern, als Hunderte Seiten, die dann nur die https Adresse beinhalten werden... Ich kann die Vorlage vorbereiten, ist ja nicht so viel Arbeit, mach ich dann bald und schauen wir mal. Yomomo 22:56, 18. Dez. 2020 (CET)

Außerdem werdet ihr jedes Mal die Meldung sehen müssen... Also hier ein Beispiel: Benutzer:OpenRewi/ Weiterverwendung

und das gleiche mit Namen für den Wikilink: HIER


In der Druckversion wirst du dann so was sehen:

https://de.wikibooks.org/wiki/Benutzer:OpenRewi/_Weiterverwendung

Wenn du die _ in der https-Adresse nicht brauchst, geht das auch leicht... Yomomo 23:13, 18. Dez. 2020 (CET)

Die Funktion und das Aussehen der Vorlage kann man auch leicht mit einem switch für alle Seite anpassen, die z.B. mit OpenReWi anfangen... Yomomo 23:16, 18. Dez. 2020 (CET)

Ooops, das ist nicht genau gelungen, ich muss noch ein bisschen experimentieren... Yomomo 23:27, 18. Dez. 2020 (CET)

Ich weiß nicht, ob ich es richtig sehe, aber denkt daran, dass das alles nur dann funktioniert, wenn OpenRewi auch plant "Druckversionen", wie sie hier üblich sind, anzulegen. Die include-tags benötigen zwingend eine Transklusion, wie in Jürgens Beispiel. Und wenn Ihr eine Vorlage anlegt, denkt daran, sie für den Visual Editor vorzubereiten, also mit entsprechendem Template-Data, sonst nützt es OpenRewi nichts. Da sich die Projektmitarbeiter auf nahezu vollständige Nutzung des VE vorbereiten. --HirnSpuk 01:40, 19. Dez. 2020 (CET)

Naja, ich pack es einfach nicht, ich lösche es, und wenn jemand es besser kann, kann er/sie es übernehmen... Sorry Yomomo 02:11, 19. Dez. 2020 (CET)

Danke Hirnspuk für den Hinweis mit den TemplateData. Ich hab jetzt eine Idee, die zumindest vorläufig halbwegs eine Lösung anbietet. Mit dieser Lösung kann jeder Seite eine "Druckversion" haben, wenn eine neue Seite mit dem Zusatz / Druckversion und Inhalt {{:Seitenname}} erzeugt wird. Ich hab nichts in Richtung class="printonly" gefunden und ich kenne mich da nicht aus... Dieser Lösung könnte jede*r benutzen (ich auch) LG!Yomomo 18:40, 19. Dez. 2020 (CET)

Nach aktuellem Plan müsste OpenRewi dann aber {{subst:Seitenname}} benutzen, wenn ich es richtig verstehe, führen sie ihre Konvertierung über eine Kopie des Wikiquelltextes durch. Aber vielleicht warten wir einfach mal ab. Ich persönlich halte eine Nutzung von "normalen" Wikilinks nicht für nötig. Bei Löschungen würde es die Sache zwar schwieriger machen, wegen Entlinkungen etc. aber so wie es im Moment aussieht, würden sich solche Probleme ja in Grenzen halten. Ich denke man kann die Sache erstmal laufen lassen und gucken, wie es sich entwickelt. Stellt man Probleme fest, muss man das System halt ändern. Ist aber nur meine Meinung.

Bzgl. der Druckversion gibt es schon entsprechende Prozedere: Guckst Du hier → Hilfe:Fertigstellen/_Druckausgaben. Allerdings weiß ich nicht, ob OpenRewi das System nutzen wollen. Ich für meinen Teil bin auch kein Fan davon, weil Autori:nennungen verloren gehen (nicht dass ich die unbedingt für nötig hielte, aber im aktuellen System ists nunmal so).

Bezüglich onlyprint gibt es eine zurückgewiesene Idee auf Phab:T52750. Scheint als könnten wir da lokal etwas gegen tun, was ich durchaus für wünschenswert hielte. Das scheint aber eine Aufgabe für geballte Adminpower, falls gewünscht.

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

Ich hab den Eindruck, dass es nicht klar ist, was ich gemeint habe. Hilft vielleicht dieses Beispiel hier klicken und hier klicken? In dieser Art kommt die Meldung (das diese keine richtige innere Verlinkung sei) beim "Veröffentlichen" gar nicht mehr vor... Yomomo 21:25, 19. Dez. 2020 (CET)

Ist mir schon klar, was Du meinst. Hast Du elegant gelöst, Kompliment! Ich kann nur nicht beurteilen, ob das für OpenRewi funktioniert oder nicht, solange wir nicht präzise ihren Export-Prozess kennen. Eine Vorlageneinbindung in der Druckversion ist halt nicht zielführend, wenn sie den Wikiquelltext in einen externen Konverter Copy-Pasten, wie ich es bisher verstanden hab. Da sehe ich nur den Umweg über eine vollständige Druckversion mit entsprechenden "subst" Anweisungen. Eventuell sogar innerhalb der Vorlage, wenn das geht, sonst ist ja in der Druckversion immer noch die Vorlage im Quelltext und nicht der korrekte Link. --HirnSpuk 21:44, 19. Dez. 2020 (CET)

Danke euch für die ganzen Experimente und Tipps. HirnSpuk hat Recht. Im Moment würde wir den Wiki-Quelltext tatsächlich ganz stumpf kopieren und die daraus erstellte Textdatei durch den Pandoc-Konverter jagen. Viele Grüße, max --OpenRewi 14:56, 21. Dez. 2020 (CET)

Problematische Inhalte[Bearbeiten]

Durch eine kürzlich erfolgte Änderung stolperte ich darüber: Spezial:Diff/641777/948667. Das finde ich hochgradig problematisch. Den Originaltext auch schon. Ist halt durchgerutscht, aber ich denke da sollten wir schleunigst tätig werden. Vorschläge? Umfangreich prüfen? Einfach löschen? So kann es in meinen Augen nicht stehen bleiben. --HirnSpuk 23:28, 18. Feb. 2021 (CET)

Danke Hirnspuk. Ich hab es zurückgesetzt und dazu die alte durch die neue Originalversion auf Englisch (die auch nicht gerade unproblematisch ist) ersetzt. Ich weiß nicht, ob jemand das Buch übernehmen kann, schauen wir mal... LG Yomomo 02:47, 19. Feb. 2021 (CET)

Welche Wirkung hat es wohl auf Sarina Beier, dass ihre Übersetzung kommentarlos entfernt wurde? Ist das die Art, wie mit neuen Benutzer:innen umgegangen werden soll? Seid ihr sicher, dass ein Text, den ihr schreiben würdet, weniger problematisch wäre? Außerdem muss sich der Text in de-WB nicht dauerhaft an dem in en-WB orientieren, sondern kann Situation und Entwicklung eigenständig darstellen. Vergleicht doch beispielsweise, was aus en:Wikijunior:Europe oder en:Wikijunior:How Things Work (noch sehr unvollständig) wurde. -- Jürgen 07:26, 19. Feb. 2021 (CET)

Ja jürgen, da hast du Recht, allerdings glaube ich, dass du einverstanden bist, dass der Satz:

"Zu Beginn des 21. Jahrhundert, hatte der Kontinent Schwierigkeiten mit Unruhen unter seinen Millionen von Immigranten, meist aus islamischen Ländern, die oft eine niedrige wirtschaftliche Position einnahmen und keine kulturelle Assimilation anstrebten oder wünschten. Vorfälle von Konflikten und Gewalt stiegen, während unvermindert weiterhin Menschen nach Europa kommen wollten."

auch kommentarlos entfernt werden sollen darf... Auch wenn das englische "Original" (mit gleichem Inhalt) seit Ewigkeiten da steht. Letzteres allerdings kann ich dadurch verstehen, dass in einer kleine Community wie unsere, so was unbemerkt bleiben kann.

Was ich in der Bearbeitungsseite des Kapitels ganz oben notiert habe:

"Wer hier arbeiten will, soll zuerst zumindest den entsprechenden Text in englischem Wikibooks schauen und auch dort notwendige Änderungen führen, z.B. was Argentina und Falkland betrifft, wo es halt laut UN-Commission nicht ganz eindeutig ist, wem die Inseln gehören sollen..."

Ich hoffe, dass du auch zumindest mit dem zweiten Teil des Kommentars einverstanden bist (vergleiche mit der englischen Version, wo die Sache als Invasion Argentinas ohne weiteres Kommentar beschrieben wird)... Den ersten Teil des Satzes ("den entsprechenden Text in englischem Wikibooks schauen") hab ich aus den in meinen Augen offenbaren Grund geschrieben, dass der Text in der Tat als Übersetzung der englischen Seite erscheint. Hast du andere Vorschläge? Gern können wir anders reagieren... LG! Yomomo 07:58, 19. Feb. 2021 (CET)

Ich möchte mich auch aufregen, am liebsten über euch: Warum nimmt bitte niemand freundlichen Kontakt zum Autor auf? --Qwertz84 10:53, 19. Feb. 2021 (CET)

Ich gebe zu, dass ich weder den englischen Text noch die Übersetzung richtig gelesen habe. Mich hat primär gestört, dass die Übersetzung vollständig entfernt wurde, ohne dass Sarina Beier angesprochen wurde. Der eingefügte Hinweis ist angemessen. -- Jürgen 11:57, 19. Feb. 2021 (CET)

Danke für die Reaktionen. Ich hoffe, dass es jetzt für alle passt. LG!Yomomo 15:06, 19. Feb. 2021 (CET)

Eigentlich hatte ich mich hierher gewandt, um eine schnelle Überreaktion zu vermeiden. Schließlich stand der Inhalt nur halt auf Englisch bereits über Jahre dort. Zuerst nahm ich an, es handele sich um ein "Unterjubeln" und war auch schon auf dem Weg zum Button zurücksetzen, bis ich feststellte, dass der englische Text genauso ist. Wir sollten vielleicht generell mal diskutieren, wie wir mit solchen Fällen umgehen wollen. Ich war schon immer gegen kommentarloses Zurücksetzen. Was meint Ihr, fällt das hier unter Theoriefindung? Ich meine ja. Soziokulturelle Integrations- und Migrationsprobleme ja, "restiveness among its millions of immigrants, mostly from Islamic nations, who often occupied low economic positions and did not seek or desire cultural assimilation" nein. Zumindest nicht ohne fundierten Nachweis.

Ein weiterer Hinweis @Yomomo, wenn Du den aktuellen Text aus dem englischen kopierst, müsstest Du meines Wissens nach, um der Lizenz genüge zu tun, auch die Autorennennung auf der Diskussionsseite aktualisieren. Ein Admin sollte das wissen. Das nächste Mal besprechen wir das vielleicht erstmal hier in Ruhe?

Gruß --HirnSpuk 18:10, 19. Feb. 2021 (CET)

Stimmt :-). passt... Allerdings, zu meiner "Verteidigung": das war eben so seit Ewigkeiten... Yomomo 18:44, 19. Feb. 2021 (CET)

Allowing video game strategy guides[Bearbeiten]

It seems that de.wikibooks does not allow strategy guides of video games. Us at en.wikibooks have decided to allow video games after 15 years (see the new policy and the proposal). This community may also want to consider allowing video game guides as a result, though you are not "forced" to in any way. Please ping me if you have any questions, since I don't watch this page. Thanks in advance. Leaderboard 20:31, 14. Mär. 2021 (CET) links fixed -- Reise Reise 21:48, 14. Mär. 2021 (CET)

zusammenfassende Übersetzung: die englischen Wikibooks erlauben nun nach Diskussion Videospiel-"Leitfäden" (Komplettlösungen?), vgl. die oben gegebenen Links (Englisch!). Kurzfassung der Diskussion: Warum nicht, vielleicht schreibt dann auch jemand was anderes. Kurzfassung der Regeln: Urheberrechte beachten, keine Theoriefindung, keine Werbung, "akademisch" schreiben. Benutzer:Leaderboard läd ein diesem Beispiel zu folgen.

@Benutzer:Leaderboard, Thank you very much for the info, I translated a short version of it. We will talk about it when the time comes. At the moment, given the community structure here on german de-wikibooks, there will probably not be a policy-change in german Wikibooks. I will follow your process on en.wikibooks and am looking forward to its results. Best regards --HirnSpuk 03:53, 15. Mär. 2021 (CET)

Downloads aus Web-Archiv[Bearbeiten]

Ich versuche vergeblich den Download von PDFs aus einem Web-Archiv. Konkret geht es um folgendes Problem:

Siegfried Petry hatte für seine Bücher auf seiner eigenen Homepage si-pe.de aktualisierte PDFs zur Verfügung gestellt. Diese Homepage gibt es nicht mehr, ist aber über Web-Archiv zu erreichen. Auf den verschiedenen Unterseiten werden eine Reihe von PDFs genannt. Der Download gelingt mir aber nicht:

  • Beim Klick auf "Download" wird kurz "loading ..." mit error 302 und "redirecting" angezeigt. Dann lande ich auf einer Spezialseite von web.archive.org mit dem Hinweis, dass diese URL (also die mit der PDF) nicht archiviert wurde, aber zu finden sei. Klicks darauf liefern weitere Informationen über diese Archivierungen, aber keine PDF zum Download.
  • Bei einem früheren Versuch hatte ich eine Datei als PDF herunterladen und lokal speichern können. Aber beim Aufruf mit einem PDF-Viewer gab es nur die Fehlermeldung, dass die Datei wegen eines falschen Formats nicht geöffnet werden könnte (mehrere Dateien, mehrere Viewer). – Leider habe ich alle Versuche gelöscht und kann es nicht rekonstruieren.

Siegfried Petry hatte in der Anfangszeit viel für Wikibooks beigesteuert und hat es (trotz einiger umstrittener Darstellungen) verdient, dass seine Bücher weiterhin genutzt werden können. Ich möchte deshalb funktionierende Links für den PDF-Download eintragen. Kann jemand helfen, wie das mit Web-Archiv geht? -- Danke! Jürgen 10:25, 3. Apr. 2021 (CEST)

Ich gehe davon aus, dass die PDF Version nicht mehr gespeichert ist, da die Seite nicht mehr existiert und das Dokument (vermute ich) nicht gespeichert wurde. Ich kenne mich da auch nicht besonders gut aus. Ich würde es eher mit dem Werkzeug von Dirk versuchen, eine PDF version zu erzeugen und sie dann in Commons speichern... Schade, dass die Version von der jetzt gelöschte Seite nicht in Commons steht... Ich hab allerdings zwei links für zwei andere Bücher gefunden, ich gehe davon aus, dass du sie auch schon hast: https://sbfc68b455c9c065d.jimcontent.com/download/version/1500886657/module/10316304695/name/Das%20Zwillingsparadoxon.pdf und https://sbfc68b455c9c065d.jimcontent.com/download/version/1456568278/module/10174952095/name/Die%20f%C3%BCnf%20gro%C3%9Fen%20Dem%C3%BCtigungen%20der%20Menschheit.pdf lg! Yomomo 12:42, 3. Apr. 2021 (CEST)

Mir ist eben nicht klar, ob PDFs mit ins Archiv kopiert werden. Die englischen Beschreibungen verstehe ich nicht richtig. – Das Zwillingsparadoxon kann ich einfach hier hochladen; danke für den Link. Die "Demütigungen der Menschheit" gibt es bei WB nicht, sind also nicht wichtig. -- Jürgen 14:05, 3. Apr. 2021 (CEST)

Einige Dateien sind noch verfügbar:
-- Reise Reise 14:41, 3. Apr. 2021 (CEST)

Klasse, das sieht nach einer sehr vollständigen Liste aus nach dem, was ich in der Vergangenheit auf seinen WB-Seiten gesehen habe. Was meint ihr: Sollte ich die Links in seinen Büchern einfach umleiten, oder sollte ich die PDFs nach WB hochladen (sofern noch nicht geschehen)? -- Jürgen 15:27, 3. Apr. 2021 (CEST)

Ich bin für "auf jeden Fall zu Wikibooks". Wenn seine Seite down ist, ist die Frage, wie lange die von Reise Reise verlinkten Inhalte zur Verfügung stehen. Das Internet vergisst zwar nie, so sagt man, aber einen internen Wikibooks-Link (oder nach Commons) finde ich allemal schicker, als einen Link nach draußen. Zumindest, wenn die Lizenzen das zulassen. Danke, falls Du Dir die Arbeit machst. Falls im Prozess erforderlich, habe ich einen Kontakt zu wahrscheinlich Verwandten recherchiert. Viele Grüße --HirnSpuk 16:57, 3. Apr. 2021 (CEST)

Reise-Reise, danke für die Arbeit, solange CC usw (wiki Regeln angehalten) bin ich mit Hirnspuk LG! Yomomo 19:30, 3. Apr. 2021 (CEST)

Am sinnvollsten fände ich einen Upload auf Commons. Dafür ist es ja schließlich da :) --Scantasyundfiencefiction 22:20, 6. Apr. 2021 (CEST)

Link auf Quelle bei Autorenliste[Bearbeiten]

Hallo!

Ich habe gerade in einem unserer Bücher neue Kapitel über copy/paste erstellt und dann die Autoren-Liste auf der Diskussionsseite erstellt. Allerdings wird dabei der Link zur Quelle nicht richtig angezeigt. Was mache ich falsch?

Auf diese Seite sollte die Quelle eigentlich verweisen.

LG Max --Maximilian.Petras 10:49, 5. Apr. 2021 (CEST)

Als Projektcode einfach nur "b" für Wikibooks eintragen, dann funktioniert der Link. Die Projektcodes findest du hier: Spezial:Liste der Wikimedia-Wikis.-- Reise Reise 11:19, 5. Apr. 2021 (CEST)

Ah! Ich danke dir!--Maximilian.Petras 20:57, 6. Apr. 2021 (CEST)

Hilfe bei Missbrauchsfilter 4 – bzgl. Hebräisch[Bearbeiten]

Wer versteht worum es geht und in der Lage ist das anzupassen, könnte mal einen Blick hierhin werfen: Spezial:Diff/947540/954246. Ich fühle mich ein wenig überfragt. Gruß --HirnSpuk 15:23, 7. Apr. 2021 (CEST)

Problematische Inhalte II – problematisches Verhalten[Bearbeiten]

Moin, meine Geduld ist erschöpft. Ich komme bei dieser Sache alleine nicht mehr weiter. Hier erfolgt ein Hinweis darauf, dass ich Inhalte und Verhalten teilweise nicht in Ordnung finde. Wer sich damit näher beschäftigen möchte, kann das auf dieser Zusammenfassung tun: Benutzer_Diskussion:Yomomo/_COVID-Dialoge#Umfassende_Stellungnahme

Eine Warnung: Alleine die Beschäftigung mit der gesamten Materie bedarf erheblichen Zeitaufwands. Wer es bevorzugt sich ein eigenes Bild zu machen, ohne meinen (logischerweise persönlich gefärbten) Überblick zu lesen, werfe einen Blick auf:

Hier werden meines Erachtens nach Inhalte auf problematische Weise entwickelt. Im Ergebnis stehen auf entsprechenden Seiten dann problematische Inhalte (Meinungen, Polemik, rhetorische Ablenkungen).

Außerdem wurden Admin-Privilegien für eigene Zwecke eingesetzt, ohne das mit der Gemeinschaft abzustimmen. Soweit noch nicht unbedingt dramatisch, aber das durch einen Fehler entstandene Chaos wurde auf mehrfachen Hinweis nicht aufgeräumt. Ich finde die verantwortliche Person möchte sich bitte selber kümmern. Ich bin jetzt alle mit Motivation und Zeit. Ich möchte auch wieder Dinge tun, die Spaß machen. Daher übergebe ich die Situation jetzt über diese und die Seite Wikibooks Diskussion:Administratoren#Problematische Inhalte – problematisches Verhalten dem Wikiprinzip, der Gemeinschaft und Schwarmintelligenz. Gruß --HirnSpuk 13:33, 13. Apr. 2021 (CEST)

Enabling global sysops on this wiki[Bearbeiten]

(apologies for writing in English)

Hi, I propose allowing global sysops to work on this wiki. It is currently not enabled because the community has >= 3 active sysops (regardless I couldn't find an opt-out discussion either), but I strongly recommend that the community opt-in because they often help in combating spam and vandalism. As an en.wikibooks admin, I can attest to the work they do and have no issues with them at all. Thanks in advance, and please ping me if you need further input, since I don't watch this page.

P.S: Global sysops won't interfere with normal Wikibooks matters (for instance they do not have access to Special:UserRights) - their role is codified in the policy page and is more or less handling spam or vandalism. This wiki can enact a global rights policy if needed (not sure if this wiki has one). They'll only help you. Leaderboard 11:25, 12. Mai 2021 (CEST)

Übersetzung/Translation (for your convenience, ping@Leaderboard): Hallo, ich empfehle, dass globale Admins die Erlaubnis bekommen hier arbeiten zu dürfen. Das ist hier zur Zeit nicht aktiviert, weil es mehr als 3 aktive Admins gibt (wobei ich keine entsprechende Diskussion finden konnte, dass wb-de globaler Admin-Tätigkeit aktiv widersprochen hätte). Ich möchte das sehr empfehlen, weil die globalen Admins oft bei Spam und Vandalismus helfen. Als wb-en Admin kann ich sagen dass es überhaupt keine Probleme damit gibt. Danke im vorraus, und bitte gebt bescheid, wenn mehr Infos gewünscht sind, da ich dieser Seite hier nicht aktiv folge.

P.S: globale Admins mischen sich nicht in die Abläufe auf den lokalen Projekten ein (z. B. haben sie keinen Zugriff auf Spezial:Benutzerrechte) – ihre Rolle ist in Richtlinien festgelegt und bezieht sich vornehmlich auf die Bekämpfung von Spam und Vandalismus. Dieses Wiki kann sicher auch eine Richtlinie für globale Rechte festlegen (vgl. Richtlinie en-wb), falls gewünscht (ich weiß nicht, ob es vielleicht schon eine gibt). Die globalen Admins würden nur helfen. Übersetzt von HirnSpuk 12:34, 12. Mai 2021 (CEST)

Als Admin mit immer weniger Zeitressourcen für Wikibooks bin ich dafür. Ich denke, je mehr Personen Admin-Tätigkeiten auf Wikibooks übernehmen (sei es auch nur um Vandalismus und Spam zu bekämpfen), desto besser ist es. Welche Meinungen habt ihr? -- Stephan Kulla 14:49, 13. Mai 2021 (CEST)

Wäre auch dafür... Ohne aber :-) LG! Yomomo 15:57, 13. Mai 2021 (CEST)

neutral(Meinung geändert, s. u.) Ich bin unentschlossen und neige zu einem "wir kommen schon klar". Da Yomomo aber quasi der Einzige direkt betroffene ist, würde ich seine Meinung hier schon sehr hoch bewerten. Außerdem möchte ich dem Ansatz widersprechen: "Je mehr Personen Admin-Tätigkeiten [...] übernehmen, desto besser [...]" Das halte ich nur dann für korrekt, wenn alles super läuft. Und das ist nicht sicher zu stellen. --HirnSpuk 16:11, 13. Mai 2021 (CEST)

Kann ein englischsprachiger spam-Jäger gut beurteilen, was hier auf Deutsch als spam anzusehen ist? Wie oft kommt solch ein Problem vor im Vergleich zu sprachunabhängig erkennbarem spam? Davon könnte abhängen, wie nützlich dies wäre. spam kann ja ohnehin zunächst einmal jeder ohne besondere Rechte begutachten. Doktorchen 16:20, 14. Mai 2021 (CEST)
Benutzer:Doktorchen Yes. Global sysops (and rollbackers for that matter) have experience handling spam and vandalism in unfamiliar languages (one thing that is looked at when a user applies to be one is their experience handling in languages they do not speak). In general, spam in any language is easy to detect, and Google Translate is very much effective from my experience. They are normally cautious when it's a less clear-cut case.
Just to note, it's not just a case of spam, it's also cross-wiki vandalism (which often happens in English irrespective of target wiki) and harassment that global sysops can help in. A filter can handle most spam; cross-wiki vandalism or harassment is harder to manage with a filter. Leaderboard 21:28, 14. Mai 2021 (CEST)

@Benutzer:HirnSpuk, in your opinion, is there consensus to enable global sysops on this wiki? If I understand correctly, I see a neutral vote, two supports and a question, but I could have misinterpreted something. Thanks in advance. Leaderboard 10:10, 19. Mai 2021 (CEST)

@Leaderboard, thanks for the proposal and thanks for thinking about wb-de. Though you are right in two support, one neutral and one question (note: as of June 18th this is not correct anymore: we now have 3 support, 1 oppose with a possible ongoing discussion --Viele Grüße, HirnSpukDisk – 00:55, 18. Jun. 2021 (CEST)), I think a week is to less time to really say something (though I'm not really expecting more input). And I think it's not on us (meaning you as new to wb-de and me as a "simple" editor) to carry the information to meta. On the given page one can read "Projects may opt-in or opt-out at their own discretion if they obtain local consensus." So I think it should be the task of one of our sysops to contact a steward to change this. It's my believe this should be done within their timeframe. If there is no activity for a month, I'd ping the sysops, and when there's no reaction, it's early enough to act. As from my experience, we don't have a lot of trouble with spam (which is easy to handle, just remove hyperlinks and mark for deletion) and vandalism. Which can be a little problem with subtle instances, but experience shows, the wiki-principle seemingly does it's thing over time. Probably not as fast as it should, in an ideal world, but I assume other underlying problems here, than simply having more people fighting vandalsim. Best regards --HirnSpuk 12:51, 19. Mai 2021 (CEST)

@Benutzer:HirnSpuk Hi, if consensus is obtained in a wiki, then any user can ask the stewards to action it (I did it for en.wikivoyage). That being said, if you rather have a local sysop do the work, that's fine by me. Same if you want more discussion time (but as you noted, I am not sure I would get any more input). Leaderboard 13:45, 19. Mai 2021 (CEST)

Symbol support vote.svg Pro Current fact is, that Yomomo is the only active admin here. And I don't see any disadvantages in accepting your help. Qwertz84 22:02, 19. Mai 2021 (CEST)

@Leaderboard, just out of curiosity, if you find the time; is this something, that might happen: Spezial:Diff/961452/961453? Thanks and regards --HirnSpuk 12:40, 27. Mai 2021 (CEST)

@HirnSpuk Very unlikely. The user who made the mistake does not have any global permissions and is neither a global rollback nor a global sysop. And if such an error does happen, it would be reasonable to let the user know that they made a mistake. Leaderboard 13:10, 27. Mai 2021 (CEST)

@Leaderboard, thank you very much, that's exactly what I was anticipating, but I wanted a second opinion. Thanks again, regards --HirnSpuk 14:05, 27. Mai 2021 (CEST)

Symbol oppose vote.svg Contra Ich habe ein wenig recherchiert und möchte meine Meinung ändern: Ich habe Sorge, dass SLAs schneller bearbeitet werden. Zur Zeit finde ich die Ruhe, die dabei aktuell drin ist, sehr angenehm. Darüber hinaus mache ich mir Sorgen, dass globale Admins hier unter Umständen Schwierigkeiten haben könnten, sich in unseren Richtlinien zurecht zu finden. Da wir es nicht schaffen werden eine Richtlinie für Globale Admins "mal eben" einzurichten habe ich meine Meinung also zu contra geändert. Viele Grüße, HirnSpukDisk – 00:55, 18. Jun. 2021 (CEST)

Symbol suggestion vote.svg Kommentar Organisation

english: Comment for whom it may concern: I think this decision should not be rushed and I'm on it. I did not forget, I contacted Yomomo and Stephan in their role as Admins for another round of Feedback as I proposed above. If they still stand by their opinion above, I'll take care for the opt-in at meta (given they wouldn't like to themselves). Feel free to discuss further here. Additionally the weather ist not really Wikimedia-friendly right now, so enjoy an icecream!

deutsch: Wen es interessiert: Ich finde, wir müssen das nicht übers Knie brechen und ich kümmere mich. Ich habs nicht vergessen. Ich hab Yomomo und Stephan als Admins kontaktiert, für eine weitere Runde Feedback, wie ich es oben vorschlug. Wenn sie immer noch obiger Meinung sind, kümmer ich mich um das Opt-in (falls sie das nicht selbst wollen). Diskutiert hier gerne weiter. Zusätzlich ist das Wetter nicht gerade Wikimedia-mäßig, also genießt ein Eis!

8-) Viele Grüße, HirnSpukDisk – 00:55, 18. Jun. 2021 (CEST)

Actually, spam and Vandalism is currently rather limited in German Wikibooks. HirnSpuk expressed some worries, which I can understand. So, I would rather change my mind and not support the idea. On the other hand, due to personal reasons, I don`t know how long I will be still activ in Wikibooks. So in this case, maybe a new Admin or the global Sysops will be necessary. Greetings Yomomo 19:04, 26. Jun. 2021 (CEST)

Da ich vermute, dass das "rather limited" (Actually, spam and Vandalism is currently rather limited" → "Tatsächlich sind Spam und Vadalismus eher begrenzt") auch (oder möglicherweise sogar überwiegend) auf Jürgens Einsatz bei den Missbrauchsfiltern zurückgehen könnte, würde mich seine Meinung interessieren (Ping@Benutzer:Juetho, falls Du die Zeit und Muße findest, herzlichen Dank). Viele Grüße, HirnSpukDisk – 13:55, 2. Jul. 2021 (CEST)

Symbol oppose vote.svg ContraFür die Absicht gegen Spam vorzugehen reicht eine Nachricht an unser Admin-Team. Es sollte über eine Ping-Vorlage nachgedacht werden, die alle Gruppenmitglieder (Admin-Gruppe) benachrichtigt. Rechte von globalen Admins mögen derzeit keine Probleme machen, aber was ist mit der Zukunft? Allein um Aktionen zu widersprechen, ist der Aufwand enorm. Mein Englisch lässt einiges zu wünschen übrig um mich dann durch den Dschungel zu lesen. Und was ist, wenn Politik mit am Werk ist? Wenn Trump-Befürworter oder Gegner, Brexit-Befürworter oder Gegner oder sonstige globalen Irgendetwas-Befürworter oder Gegner auf die Idee kommen, global was zu ändern? Alles undenkbar? Die kommunale Selbstverwaltung halte ich für den besten Weg. Globale Probleme können anders gelöst werden. Oder gibt es derzeit globale Spam-Attacken? --mjchael 11:42, 7. Jul. 2021 (CEST)

Symbol neutral vote.svg Neutral Seit der ersten Frage hier bin ich unsicher, ob global sysops hilfreich sein könnten. Ich habe lange gezögert mit einem Kommentar, auch noch nach dem expliziten Ping...

Ob "meine" Missbrauchsfilter wirklich so wirksam gegen Spam und Vandalismus waren, bezweifle ich inzwischen. Gegen manche Aktionen stimmt das, aber genauso wirksam sind die globalen Missbrauchsfilter, die es seit einiger Zeit (zwei Jahre?) gibt. Jedenfalls werden viele derartige Versuche gemäß Logbuch dreifach vereitelt – von zwei globalen und einem lokalen Filter. Außerdem gibt es für diese Art von Problemen ein Auf und Ab.

Für viele Probleme wird keine Admin-Funktion benötigt. Auch „normale“ Nutzer:innen können Unsinn rückgängig machen – danke vielmals an HirnSpuk für vielfältige Aufmerksamkeit. In der Zeit, in der ich als Admin fast alleine aktiv war, hatte ich das vermisst. Die richtige Mischung macht es: ein paar aktive Admins, ein paar aufmerksame Nutzer:innen, Autor:innen, die auf umfangreiche Projekte (hier: MfNF, OpenRewi) selbst aufpassen... Wenn es aber nicht „ein paar“ sind, sondern einzelne, könnten global sysops unterstützen. -- Jürgen 17:23, 15. Jul. 2021 (CEST)

Danke Jürgen! Ich fasse zusammen, alle außer den Zustimmenden scheinen sich bestenfalls unsicher zu sein. Die Abstimmung ist denkbar knapp mit ein paar Meinungsänderungen: 2 Symbol support vote.svg Pro – 2 Symbol neutral vote.svg Neutral – 3 Symbol oppose vote.svg Contra.

Ich setze für eine gewisse Zeit noch keinen erledigt-Baustein, falls noch Argumente dazu kommen. Mein Angebot steht mich zu kümmern, ich denke aber dass das tatsächlich aus der Administration heraus kommen muss (in diesem Fall könnt Ihr mich gerne ansprechen). Bei aktuellem Stand sehe ich keinen Handlungsbedarf, da die Abstimmung von Nutzern mit Adminrechten 1 Symbol support vote.svg Pro – 2 Symbol oppose vote.svg Contra steht.

english Summary: The current opinion regarding enabling global sysops is "2 Symbol support vote.svg Pro – 2 Symbol neutral vote.svg Neutral – 3 Symbol oppose vote.svg Contra". This is too close for me to become active. But I will if it becomes necessary in the future. Best regards.

Viele Grüße, HirnSpukDisk – 18:45, 15. Jul. 2021 (CEST)

Ich hätte gerne Feedback zu einer geplanten Umfrage[Bearbeiten]

Moin zusammen,

Ich habe mich bei Spezial:Permanentlink/961435#Ich_befürchte,_wir_haben_mehrere_Probleme dafür entschieden eine Umfrage zu erarbeiten. Zu besichtigen ist diese nun unter Wikibooks:Projektentwicklung/2021/Umfrage Grundsätzliche Meinungen (Die reinen Fragen befinden sich im Abschnitt Umfrage. Hinweis: Es wird sich bei der späteren Umfrage um eine Vorgabe handeln, vgl. Vorlage:Vorgabe, daher befinden sich die Antwortvorgaben im Quelltext. Die Umfrage steht hier nur zur Voransicht und Vorabdiskussion, vgl. Abschnitt Todo). Bei der Länge habe ich mit mir gehadert und überlegt was am sinnvollsten ist. 40 Minuten ist mir eigentlich zu lang, aber mehrere Umfragen nacheinander finde ich auch blöd. Daher habe ich einfach beide Varianten vorgesehen, die parallel laufen können. Das macht die Auswertung zwar anstrengender, aber es erschien mir am sinnvollsten für den maximal möglichen Informationsertrag. Die Links und Fristen etc. sind natürlich alle noch nicht scharf geschaltet. Ich hätte vorher gern noch Feedback.

Folgende Fragen hab ich:

  • Haltet Ihr den Umfrage-Zeitrahmen für sinnvoll (6 Wochen)?
  • Für die Werbemaßnahmen benötige ich Admin-Unterstützung. Geht das? Stefan, Yomomo, habt Ihr einen besonderen Frist-Wunsch?
  • Können noch weitere Werbemaßnahmen getroffen werden?
  • Sind Fragen zu viel (bitte mit Begründung)
  • Fehlt eine Frage (bitte mit Begründung)
  • Ist alles verständlich?
  • Sind Fehler drin?
  • Bitte gerne die Bearbeitungszeit-Schätzung von 40 min. prüfen, wenn Ihr die Zeit investieren wollt, danke. Ich hab ungefähr 20 Min. gebraucht, ich hab die Fragen aber auch geschrieben und eine ziemlich gute Vorstellung meiner Antworten gehabt.

Größere Punkte bitte auf der Seite Wikibooks Diskussion:Projektentwicklung/2021/Umfrage Grundsätzliche Meinungen thematisieren. Bitte haltet Euch kurz und haltet Euch nicht an Kleinigkeiten auf. Wenn alles gut geht, werden sich hoffentlich weitere fruchtbare Gespräche und Entscheidungen anschließen, dann ist es immer noch früh genug sich mit Details zu beschäftigen.

Wer keine Fragen, Hinweise, Hilfen oder Anmerkungen hat, kann gerne das Bedanken-Feature (für diesen meinen Eintrag hier in der Versionsgeschichte) benutzen, dann kann ich sehen, wer diesen Beitrag zur Kenntnis genommen hat. Ich bitte alle, die das hier lesen und die Aktion gut finden, im Fall der Fälle als Multiplikator zu fungieren und Leute entsprechend anzusprechen an der Umfrage teil zu nehmen.

Ich denke als erste Idee für die Dauer dieser Feedbackrunde sind 2 Wochen okay, das kann aber auch bei entsprechend fruchtbaren Diskussionen länger werden. Wenn das Feedback abgeschlossen ist, werde ich diesen Abschnitt hier als erledigt markieren und die ganze Sache starten. Herzlichen Dank für Eure Hilfe! Viele Grüße, HirnSpukDisk – 00:01, 3. Jun. 2021 (CEST)

Lieber HirnSpuk, herzlichen Dank für diese wunderbare Initiative! Die Umfrage werden wir aktiv bei OpenRewi bewerben. Die Fragen erschienen mir soweit ganz sinnvoll. LG, --Maximilian.Petras 20:27, 3. Jun. 2021 (CEST)

Moin,

  • Haltet Ihr den Umfrage-Zeitrahmen für sinnvoll (6 Wochen)?
    • Ja, 4 Wochen würden auch gehen
  • Können noch weitere Werbemaßnahmen getroffen werden?
    • Wikiversity und Wikipedia haben doch ebenfalls News-Seiten, dort könnte die Umfrage ebenfalls vorgestellt werden. Vll mal die Stewards fragen, ob die einen Hinweis auf die Umfrage auf allen DE-Projekten einblenden können?
  • Bitte gerne die Bearbeitungszeit-Schätzung von 40 min. prüfen
    • passt schon etwa
  • sonstiges: auf den Eskalations-Dingsbums würde ich verzichten. >2 Wochen lang von einem Banner genervt zu werden ist sicher auch so schon genug, siehe die regelmäßigen Spenden-Aufrufe. Stattdessen lieber aktiv Personen ansprechen, vll. auch ehemalige Autoren.

Qwertz84 22:17, 3. Jun. 2021 (CEST)

Auf eine Werbung auf anderen Wikimedia-Projekten möchte ich verzichten. Leute von dort können natürlich gerne abstimmen, wenn sie es mitbekommen, genauso, wie IP-Adressen und auch Leser. Ich habe durchaus auch Menschen, die in der Wikipedia aktiv sind um Feedback gebeten. Aber eine aktive Werbung für den Zweck halte ich für nicht zielführend. Soll gar nicht heißen, dass ich gegen eine Verzahnung der Wikimedia-Projekte bin, im Gegenteil. Aber ich halte es für sinnvoll langsam vorzugehen und für die aktuelle Fragen und Prozesse sind mir erstmal die Antworten der hier Aktiven wichtiger und ich hätte Sorge, dass sich einzig die Auswertung verkompliziert. Viele Grüße, HirnSpukDisk – 02:16, 4. Jun. 2021 (CEST)

  • Haltet Ihr den Umfrage-Zeitrahmen für sinnvoll (6 Wochen)? Ja.
  • Für die Werbemaßnahmen benötige ich Admin-Unterstützung. Geht das? Ja.
  • Können noch weitere Werbemaßnahmen getroffen werden? Werbung auf anderen Projekten halte ich für sinnlos. Wir brauchen nur die Meinung der hiesigen Autoren (frühere und jetzige).
  • Ist alles verständlich? Ja.
  • Bitte gerne die Bearbeitungszeit-Schätzung von 40 min. prüfen ... Ist schon OK, aber für einige fundierte Antworten werde ich länger brauchen.

Viele Grüße -- Klaus 14:29, 23. Jun. 2021 (CEST)


Symbol suggestion vote.svg Kommentar Organisation: Ich warte noch auf Feedback von Personen deren Meinung mir wichtig ist, ergo verlängert sich die Zeit der Feedback-Runde entsprechend. Das Wetter sagt: Nein, es gibt noch keine Zeitangabe dazu ;-). Genießt ein Eis 8-)! Viele Grüße, HirnSpukDisk – 01:00, 18. Jun. 2021 (CEST)

Hallo Hirnspuk! Danke für die ausführliche Arbeit, sieht wirklich toll aus. Ich stimme hier einfach Klaus zu! Banner hast du ja sogar auch schon vorbereitet :-) LG! Yomomo 18:22, 26. Jun. 2021 (CEST)

Locked.svg

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

Ergebnis: Die Feedbackrunde ist abgeschlossen. Ich bedanke mich für die Meinungsäußerungen und die Unterstützung. Ich habe entschieden den Administratoren die Laufzeit zu überlassen, sodass Header-Boxen/Banner nach eigenem Gutdünken und Zeitplan geschaltet werden können. Die Admins, die sich kümmern, bitte ich entsprechend auszuwählen, ob und welche Boxen verwenden werden sollen und ob sie eskalieren. Ein wenig Vorarbeit ist noch zu leisten. Ich werde wie angekündigt Einträge hier und in der Rundschau sowie ggf. an anderen Stellen hinterlassen, wenn es soweit ist. Meine weiteren Vorbereitungen können unter den oben angegebenen Links verfolgt werden. Viele Grüße, HirnSpukDisk – 10:10, 12. Jul. 2021 (CEST)

Visualisierung von (handschriftlichen) Randbemerkungen in Wikibooks[Bearbeiten]

Hi, ich hoffe, ich bin hier mit meinen Fragen an der richtigen Adresse.

Wir wollen gerne in unserem juristischen OpenRewi-Fallbuch in unseren didaktisch vorgelagerten Kapiteln verschiedene Dinge visualisieren, die angelegnt sind an (handschriftliche) Randbemerkungen. Es geht dabei z.B. um einen Notizzettel (Lösungsskizze), bei der man den Haupttext hat und dann "am Rand" noch verschiedene Anmerkungen notiert. Ich hab mich da schonmal dran versucht und das hier ist dabei herausgekommen: Lösungsskizze.

Ich habe das zum einen erstmal mit einer (unsichtbaren) Tabelle versucht: hier. Dort ist aber das Problem, dass ich es irgendwie nicht richtig hinbekomme, die Tabelle nach meinen Vorstellungen einzustellen (Spaltenbreite; selbst gewählte Zeilenumbrüche usw.). Vielleicht liegt das aber auch nur daran, dass ich nicht richtig weiß, wie man das bei einer Tabelle einstellen kann?

Deswegen hatte ich es dann hier nochmal anders, mit linksbündig eingefügten Kästen (nach dieser Anleitung), versucht. Das habe ich so dann auch durchgezogen, allerdings war das auch ziemlich umständlich und ist glaube ich sehr anfällig dafür, bei kleineren Änderungen zB in den Zeilenumbrüchen, alles "zu zerschießen". Zumal es wohl in der Handy-Ansicht nicht besonders gut einsehbar ist.

Daher ist vielleicht erstmal meine vorangestellte Frage: Welche Methode / welches Format bietet sich für so eine Darstellung am unkompliziertesten und/oder am besten visualisierbar (auch fürs Handy) an? Eine dieser beiden Formate oder ganz anders?

Noch zur Ergänzung: Das gleiche (oder ein anderes) Format würden wir dann auch für zwei andere Konstellationen nutzen wollen, bei denen seitlich

  • neben dem Sachverhalt ebenfalls Randnotizen ergänzt werden sollen;
  • bzw. neben einer ausformulierten Lösung simulierte "Kommentarierungen" einer Klausurkorrektorin dargestellt werden sollen.

Dafür dürfte sich vermutlich dasselbe Format anbieten?

Darüber hinaus haben sich bei der Visualisierung weitere, kleinere Fragen ergeben:

  • (Wie) kann man Bildelemente in so einen Randbereich einbauen, die aber nicht wie Bildelemente (mit Bildtext; separat geöffnet beim Draufklicken) aussehen sollen? Es geht dabei insbesondere um solche Blitze oder geschweifte Klammern wie hier teilweise.
  • Gibt es eine Möglichkeit, eine solche Darstellung wie im folgenden handschriftlichen Beispiel auch im Fliextext vorzunehmen, also mit nebeneinander stehenden Punkten? Oder ginge das auch wieder nur über eine eingefügte Bilddatei?
Kunstbegriff.jpg

Vielen Dank schonmal für die Unterstützung oder den Verweis auf Seiten, wo ich genauer nachlesen kann.--Ammar Bustami 22:38, 21. Jun. 2021 (CEST)

Hallo Ammar, ja da bist Du hier richtig. Ich finde, das sieht schon ganz gut aus, was Du da gebastelt hast. Dafür, dass wir bei solchen Problemen bei Wikibooks vom Satz her an unsere Grenzen stoßen, find ich das sehr schick. Ich sehe aber auch die Schwierigkeiten.

Die Fragen sind so komplex, dass es vermutlich ein Weilchen braucht, bis sie alle zufriedenstellend beantwortet sind. Ich werde mich nach Kräften bemühen Lösungsvorschläge zu präsentieren.

  • Hinweis zur Formatierung oben: Absätze brauchst Du nicht mit <br> machen, einfach eine Zeile leer lassen. Ich habe mir erlaubt das mal zu ändern. Wenn dieses Tag, dann muss es <br /> sein (frag mich bitte nicht warum, das taucht sonst in irgendwelchen "falsch-tags-verwendet-Kategorien" auf; ist wohl veraltet).
  • Tabellenformatierung: mw:Help:Tables, damit müsstest Du weiter kommen.
  • Am einfachsten ginge es wohl mit einer Tabelle, da das "zerschießen" dabei wohl "unwahrscheinlicher" ist. Und es auch immer "halbwegs" sauber aussieht, zumindest Absatz-weise. Tabellen können mobil gefährlich sein sollten aber Eurem Editierverhalten entgegen kommt. Max hatte mal gesagt Ihr macht nahezu alles im Visual Editor.
  • Soll die Darstellung wirklich so sein, also nebeneinander? Das wird dann mobil ganz schön sehr schmal.
  • Eine spontane Idee: Wie wäre vielleicht eine Art "Bewertungsbox" unter einem Absatz rechtsbündig mit verminderter Breite? Man könnte auch solche Spirenzchen machen, wie den Kasten leicht nach rechts raus schieben. Links bietet sich nicht an, weil es sonst ggf. mit dem Wikibooks-Seiten-Menü kollidiert (hier ein bisschen nach rechts scrollen)
Korrektur

Blitz1.png
So könnte das dann zum Beispiel aussehen

„Also das ist ja mal nicht so schön“ – sagt der Korrigierende

  • Oder man zieht es links sehr dezent raus und kippt die Beschriftung:
Korrektur
Blitz1.png
So könnte das dann zum Beispiel aussehen

„Also das ist ja mal nicht so schön“ – sagt der Korrigierende

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

  • Bild ohne Unterschrift habe ich oben gleich mitgezeigt, schaus Dir im Quelltext mal an. Den Link zur Datei (separat öffnen bei Klick) braucht es aus Rechtsgründen, um die Lizenz nicht zu verletzen. Ansonsten schaust Du bezgl. Bildern dort: mw:help:images
    Da das Bild von Dir ist, könntest Du es mit der CC0 Lizenz versehen, dann kannst Du den Link auch entfernen.
  • Punkte gehen entweder als Tabelle, als Bild oder als Liste:
    • Elternpunkt
      • Kindpunkt
      • Kindpunkt
      • Kindpunkt
Eine hübsch formatierbare Baumstruktur für sowas wäre mir nicht bekannt. Es gibt Leute, die machen das mit "vorformatiertem Text" (vgl. Hilfe:Seiten bearbeiten). Da hier dann jedes Zeichen die gleiche Breite einnimmt kann man dass dann per ASCII zusammenklöppeln. Ich nehme aber nicht an, dass das für Euch in Frage kommt.
  • Ansonsten, vielleicht so; das könnte man dann in eine oder mehrere Vorlagen gießen; ähnliches lässt sich sicher auch mit Tabellen realisieren; Problem: Die Zeilenumbrüche stören die Zuordnung, wenn man schmaler unterwegs ist:

ab hier: 30-40 min


wie oben


Blitz1.png



SP 3!







evtl. weglassen?







Blitz1.png



SP 4!

Verweis auf Geeignetheit?









3. Verfassungsmäßigkeit der Anwendung

vor allem Verhältnismäßigkeit → praktische Konkordanz

a) legitimer Zweck

  • Verurteilung zum Schutz der FDGO (+)

b) Geeignetheit

  • = Zweck wird zumindest gefördert
  • Problem: nur, wenn Lied auch FDGO angreift?
  • "werkgerechte Interpretation" des Lieds? War das hier gemeint?
    • Kontext: gegen Nationalismus, gegen Krieg, gegen gesellschaftl. Missstände
    • Ziel: Aufrütteln + zum Nachdenken anregen?
    • auch andere fühlten sich nicht aufgerufen (Freundin F)?
    • Verkürzung auf Wortlaut durch Gericht unzureichend!
  • hier schon: Geeignetheit (-)

c) Erforderlichkeit

Selbst wenn geeignet (+)...

  • milderes gleich geeignetes Mittel?
  • niedrigere Strafe? aber Spielraum, Erforderlichkeit (+)

d) Angemessenheit

  • Ausgleich praktische Konkordanz zwischen
    • Eingriff Art. 5 III 1
    • Schutz der FDGO
  • Pro FDGO

hohes Gut

aber: wirkliche Gefahr hier?

  • Pro Kunst

Bedeutung des Rechtsguts

Art. 5 III schon verkannt durch Gericht

intensiver Eingriff!


Angemessenheit (-)

4. Zwischenergebnis: RFG (-)

III. Ergebnis: Verletzung Art. 5 III 1 (+)

C. Gesamtergebnis

Verfassungsbeschwerde S zulässig + begründet = Aussicht auf Erfolg (+)

Wenns von Interesse ist, versuche ich das gleiche mal als Tabellenvorlage zu bauen: Dann könnte man es mithilfe von "subst:" einbinden und dann kann man in der Tabelle auch den Visual Editor benutzen.

Viele Grüße, HirnSpukDisk – 01:49, 22. Jun. 2021 (CEST)

Das ist ganz wunderbar @HirnSpuk! Mal wieder herzlichen Dank.

Ammar, an dich nur kurz die Bitte, jede Formatierungsoption sowohl mobil (am Besten Android und iOS testen - aber kein Muss) als auch in der exportierten Variante zu prüfen. Wir exportieren mit diesem Tool. Dort einfach die URL deiner Seite eingeben und als Format odt wählen. Bei Vector Graphics hat sich bis jetzt "keep vector form" bewährt. Dann in MS Office / Libre Office schauen, wie es aussieht (und nicht von den noch nicht formatierten Fußnoten irritieren lassen - das machen wir über ein Extraskript von Dirk). Wenn Du eine digitale Version baust, die besonders schön ist, aber sich nicht exportieren lässt, können wir das im größten Notfall durch das Design-Team des Verlages nachbauen lassen. LG, Max --Maximilian.Petras 09:13, 22. Jun. 2021 (CEST)

Tabelle ist falsch, wenn es sich nicht um tabellenartigen Inhalt handelt, was bei dieser Anwendung der Fall sein dürfte. Handschriftliche Randnotizen sowie ähnliche Anwendungen, wo Texte primäre als graphische Elemente verwendet werden, wären ja pauschal eher etwas für SVG (Vektorgraphik), nicht (X)HTML.
Bei (X)HTML+CSS, was ja für längere Texte deutlich sinnvoller, besser lesbar für das Publikum wird, weil sich die Darstellung automatisch an den verfügbaren Platz anpaßt, ebenso an die vom Publikum gewählte Schriftgröße. Dies bedingt allerdings auch, daß Autoren nur bedingt Einfluß darauf haben, wie der Inhalt beim jeweiligen Leser genau angeordnet sowie präsentiert wird. Mittels CSS:float bei inzeiligem Inhalt kann man natürlich etwas an den Rand schieben, ist aber immer inhaltlich problematisch, einerseits wegen der eindeutigen Zuordnung (läßt sich ebenfalls mit CSS-Dekoration regeln), ebenso hinsichtlich des inhaltlichen Sinngehaltes - was also da steht, wenn die Dekoration deaktiviert wird.
Ich würde daher eher bei weitergehende Erläuterungen, Kommentaren etc auf eine Art Glossar setzen, auf dessen Einträge vom Text verwiesen wird, vom Glossareintrag wiederum entsprechend zurück zur betreffenden Textstellen, damit sich das Publikum nicht verirrt - generell könnte man diese Einträge wohl sogar per CSS einblenden lassen, also über dem Text aufpoppen lassen, nachdem eine entsprechende Markierung mit dem Zeigergerät überfahren oder sonstwie aktiviert wird. Robuster funktioniert es indes, wenn man es bei relativ einfachen Verweisen auf Glossareinträge beläßt.
Zu <br /> oder <br> - ersteres ist XHTML/XML-Syntax, das zweite jene von HTML4. Bei HTML5 hängt es davon ab, ob man die Markierungssuppenvariante verwendet oder die XML-Variante, letztere kennt bloß <br />, weil Elemente immer geschlossen werden müssen. Bei der Markierungssuppenvariante hingegen müssen die Brauser eine Liste von Elementen vorhalten, welche immer leer sind, sich also immer selbst schließen müssen. Diese Verkomplizierung existiert bei XML nicht, da gibt es keinerlei Sonderregeln oder Ausnahmen, welche man sich merken müßte. Generell findet das br-Element ja auch eher selten Anwendung, etwa beim Notieren von Adressen, innerhalb von Absätzen etwa für kurze Pausen im Gedankengang. Warum der wiki-parser indes die Markierungssuppenvariante hier nicht mag, bleibt etwas rätselhaft, eventuell auch ein historisches Artefakt, vor der Erfindung von HTML5 wurde hier noch XHTML als Ausgabe verwendet - also, das allermeiste, was hier produziert wird, ist weiterhin XHTML1.0, es wurde primär bloß die Kennzeichnung dafür in der Ausgabe entsorgt, eventuell deshalb. Insofern hat man hier eben eher die schlechten Teile aus beiden Welten vereint. Doktorchen 09:34, 22. Jun. 2021 (CEST)

Vielen lieben Dank auch von mir @HirnSpuk! Das sieht alles schon sehr hilfreich aus, auch wenn ich es mir nochmal genauer anschauen und ausprobieren muss, um herauszufinden, was für unsere Zwecke am besten passt.

  • Momentan sieht für mich dann doch die ganze normale Tabelle am besten aus - da schaue ich gerne nochmal genauer auf dem von dir geschickten Link nach. Vielleicht kann ich ja nach noch etwas Herumprobieren nochmal nachfragen, falls weitere Unklarheiten aufkommen. Wenn ich es aber so erstmal richtig sehe, dann werden Tabellen auch im mobilen Format ganz gut angezeigt, ohne dass die Höhe der einzelnen Anmerkungen in den Spalten zueinander "verrutschen" richtig? Dein letzter Vorschlag allerdings zerschießt bei mir dann auf dem Handy auch wieder die Formatierung, daher passt das vermutlich wiederum nicht so gut.
  • Ich könnte mir auch vorstellen, dass sich für eine unserer anderen beiden Verwendungsmöglichkeiten sogar die von dir gewählten nachgeschobenen rechtsbündigen "Korrekturen" sich ganz gut anbieten könnten, aber das kläre ich mal nochmal ab.
  • Auch was das Bild einbinden angeht, kriege ich das jetzt sicher hin - versuche ich die Tage nochmal!
  • Schließlich noch eine letzte Frage (bzw. ich probiere das mal direkt aus):
    Mir hat deine kursive andere Schriftart ganz gut gefallen. Ich hoffe, das klappt jetzt so hier auch...

Alles Weitere folgt...--Ammar Bustami 13:48, 22. Jun. 2021 (CEST)

@Doktorchen: Es soll sich doch um tabellenartigen Inhalt handeln? Mit eindeutiger Zuordnung zwischen linker und rechter Spalte. Ich bin auch kein Fan von Tabellen und die Pfuscherei gefällt mir auch nicht, aber es gibt nunmal leider Notwendigkeiten. Und vieleicht ist eine Tabelle pro Absatz hier die zielführendste Lösung? Eine "Klausurkorrektur" in ein Glossar auszulagern halte ich dafür nicht. Da gefallen mir eingeschobene Kästen mit klarer Auszeichnung schon besser.

Inhaltlich (was passiert, wenn die Dekoration nicht benutzt wird) fänd ichs im meinem Beispiel oben besser, wenn erst der Inhalt und dann die Korrektur käme, das hab ich aber nicht skalierbar hinbekommen. Man müsste sicher auch die Absätze mit der Vorlage entsprechend nach Kommentar trennen, um wenigstens einen ansatzweise sinnvollen optischen Zusammenhang herzustellen.

@Ammar Bustami

  • Nein, auch bei Tabellen verrutschen die Inhalte sehr wahrscheinlich. Wenn ich es richtig sehe, ist das von der "Containerbreite" abhängig und ob das jetzt ein Div ist oder eine Zelle sollte minderwichtig sein. Für wichtig halte ich, dass es pro Absatz/Kommentar dann eine Zeile gibt. Dann bewegt sich das entsprechend sauber mit. Diese <br />-Lösung von mir und die weiße Schrift von Dir sind schon ziemlich "dirty" ;-).
  • Zur "Schriftart": Das ist nicht kursiv, das ist "Schreibschrift" (eine Form der Auszeichnung, kursiv wäre "italic" und den Unterschied zwischen schärg und kursiv spar ich mir jetzt mal :)) und sieht von System zu System, von Browser zu Browser unterschiedlich aus. In Deinem obigen Fall würde ich übrigens <span style="font-family: cursive; color: green;"> benutzen. Spart ein Div und die Vorlage.

Falls Ihr meine Beispiele ernsthaft in Erwägung zieht: Es hat sich gezeigt, dass diese "rauszieherites" die ich da oben mit den Kästen gemacht habe, dann im Ausdruck der Website käse aussieht. Sollte man also vielleicht besser lassen, wenn man darauf abzielt, dass die Seite auch ausgedruckt werden können soll. Mobil hab ichs nicht überprüft.

Viele Grüße, HirnSpukDisk – 14:53, 22. Jun. 2021 (CEST)

Ein klares Zeichen für tabellenartigen Inhalt liegt meist vor, wenn die Tabellenzellen hervorgehobene Ränder haben, entsprechend Zeilen oder Spalten eine Beschriftung über den Inhalt von Zeilen oder Spalten, bei einigen Tabellen ist eine Beschriftung von beidem redundant. Vermutlich war der ergänzte Text ja vorher keine Tabelle, die Korrekturen dazu ändern dies ja nicht. Für Korrekturen im Text sind eher del und ins gedacht, könnte man für den Zweck zusätzlich mit weiteren dekorierten Elementen umgeben. Was jedenfalls stimmt: Für Korrekturen, Anmerkungen von Korrekturlesern etc ist es mit (X)HTML nicht so einfach. Um eindeutig zu bleiben, kann man bloß mit mehr oder weniger dekorativen Elementen (i oder b, sofern dies sonst im Text nicht besonders verwendet wurde, per Klassenangabe einer CSS-Dekoration zugänglich wird - was wiederum bei wikibooks wohl so nicht sinnvoll/auffällig umgesetzt werden kann), del, ins, Verweisen bei ausführlicheren Kommentaren arbeiten, sonst wird es inhaltlich Pfusch ohne eindeutige Zuordnung zur betroffenen Textstelle bleiben - oder der ursprüngliche Text wird übel zerlegt in irgendwas komplett anderes, was mit dem zu korrigierenden Text faktisch nichts mehr zu tun hat. Derart zerlegt würde eine tatsächliche Durchführung der gewünschten Verbesserungen ja auch erhebliche Arbeit bedeuten. del uns ins sind ja transparent, dürfen also inzeilig und für Blöcke verwendet werden.
Einfachste Beispiele, wie es bei vollem Zugriff auf das (X)HTML gekennzeichnet werden kann: <del>feler</del><ins>Fehler</ins> oder <i class="Textstelle">nach Konfuzius <b class="Kommentar">Falsche Quelle? Hat das nicht vielmehr Harald Juhnke in einem Lied zusammen mit der Gruppe Extrabreit gesungen?</b></i> etc - Dekoration der Klassen ist hier bei wikibooks wohl noch immer nicht drin, etwas mühsam, bei jeder Korrektur jeweils per Attribut style die fraglichen Dekorationen reinzubasteln:
felerFehler oder nach Konfuzius Falsche Quelle? Hat das nicht vielmehr Harald Juhnke in einem Lied zusammen mit der Gruppe Extrabreit gesungen?
Doktorchen 18:50, 22. Jun. 2021 (CEST)

Ich muss jetzt mal ne dumme Frage stellen: Es geht doch hier nicht ums gemeinsame Buch-Schreiben, sondern darum Inhalte visuell strukturiert einander zuzuweisen, ob das jetzt Kommentare zu Textstellen sind, oder so getan wird, als ob ein Korrektor die Lösung korrigiert, oder nicht? Also z. B. so zu tun, als wäre man "in einer Klausur unterwegs"? Assis, die Klausuren korrigieren, "verschieben" den Text der Studis auch nicht einfach? Das soll doch hinterher exakt (also näherungsweise) so gedruckt werden, dachte ich? Aber wenn ich das falsch verstanden haben sollte, dann klärt mich gerne auf. Viele Grüße, HirnSpukDisk – 19:30, 22. Jun. 2021 (CEST)

Etwas in der Art kommt auch gedruckt vor, zum Beispiel bei veränderten Vertragsbedingungen. Gleichwohl geht es ja hier zwangsläufig um digitale Texte, insofern bleibt das (X)HTML samt semantischer Textauszeichnung ja immer die Grundlage, insofern sollte diese auch gemäß den Vorgaben umgesetzt werden. Sonst ist es wirklich sinnvoller, gleich PDF zu verwenden, ohne (X)HTML dazwischen. Per LaTex etwa postscript oder PDF zu generieren, ist wie gehabt für Druckwerke durchaus sinnvoll. Doktorchen 19:38, 22. Jun. 2021 (CEST)

Moin, nochn Vorschlag:


3. Verfassungsmäßigkeit der Anwendung

ab hier: 30-40 min

vor allem Verhältnismäßigkeit → praktische Konkordanz

wie oben

a) legitimer Zweck

  • Verurteilung zum Schutz der FDGO (+)

b) Geeignetheit

Blitz1.png

SP 3!
  • = Zweck wird zumindest gefördert
  • Problem: nur, wenn Lied auch FDGO angreift?
  • "werkgerechte Interpretation" des Lieds? War das hier gemeint?
    • Kontext: gegen Nationalismus, gegen Krieg, gegen gesellschaftl. Missstände
    • Ziel: Aufrütteln + zum Nachdenken anregen?
    • auch andere fühlten sich nicht aufgerufen (Freundin F)?
    • Verkürzung auf Wortlaut durch Gericht unzureichend!
  • hier schon: Geeignetheit (-)

c) Erforderlichkeit

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Selbst wenn geeignet (+)...

  • milderes gleich geeignetes Mittel?
  • niedrigere Strafe? aber Spielraum, Erforderlichkeit (+)

Vorteile: Text ganz normal, Der Rest per Vorlage, z. B. {{Sidenote|Rot|[[Datei:Blitz1.png|35px|links]]<br />SP 3!}}. Der inhaltliche Zusammenhang bleibt erhalten, weil der Kommentar nach dem eigentlichen Text kommt. Funktioniert aber wohl nur bei sehr kurzen Kommentaren, wie man oben sehen kann, sieht das bei langen Sachen dann nicht mehr wirklich brauchbar aus. Viele Grüße, HirnSpukDisk – 01:12, 23. Jun. 2021 (CEST)

Guckst du dir den HTML-Quelltext an, fällt auf, daß wohl die Listenstruktur aufgebrochen wird, was wiederum daran liegen könnte, daß das div mit dem Kommentar an der falschen (?) Stelle eingefügt wurde. Besser erkennbar wäre dies bei numerierten Listen. Mit span, i, b, del, ins statt div könnte dies eventuell vermieden werden, div als Block eignet sich als Einschub nach anderen Blockelementen, also nach Absätzen, Listen, Tabellen; die Phrasenelemente können hingegen direkt eine ganz bestimmte Textstelle kommentieren, del und ins als transparente Elemente dürfen beides. Käme auf Experimente an, was der wiki-parser nachher wirklich draus macht ;o) Doktorchen 08:29, 23. Jun. 2021 (CEST)

Annehmend, Du beziehst Dich auf meinen letzten Vorschlag: Wo wird denn da die Listenstruktur aufgebrochen? p ist doch ein Absatz und damit ein Block-Element? Dahinter macht sich ein Div doch dann ganz gut? Vom "Satz" her wäre es zwar davor gewünscht, aber so könnte man einen Kompromiss erreichen? Klar, wäre die Idee der Gestaltung ja vom Prinzip her eine Liste, aber so isses nunmal nicht gebaut. Was spräche denn dagegen ein schwimmendes Div sogar einem Listenabschnitt zu zu weisen? Vergiss nicht: Es geht hier in erster Linie um die Satz-Anforderungen von OpenRewi und die Tatsache dass wir hier Schreiber, Verwalter, Lektor, Korrektor, Setzer und Drucker in Personalunion sind (und im Normalfall in nichts davon richtig ausgebildet sind UND das Mediawiki-System uns enge Grenzen setzt, was überhaupt möglich ist). Ich bin ja durchaus dafür die Semantik nicht aus den Augen zu verlieren, weswegen ich dazu neige die Beifügung im Quelltext hinter dem Hauptinhalt unterzubringen, aber mir ist nicht klar, wie mit Deinen Ideen die gestalterischen Wünsche von OpenRewi umgesetzt werden können sollten. Nach wie vor halte ich die Tabelle (bei Rücksicht auf die mobile Darstellung) für am geeignetsten. Wurst ob da nun eine Beschriftung und Kopfzeile fehlt (die man ja sogar noch beifügen könnte). Viele Grüße, HirnSpukDisk – 10:11, 23. Jun. 2021 (CEST)

Ich weiß gar nicht, was solch ein OpenRewi ist (offenkundig ein relativ neues Unterprojekt hier) - die hiesige Eingabe produziert nun einmal HTML als Ausgabe, keine Druckvorlage - (X)HTML kann sich zwar mit ein paar Abstrichen zusammen mit einer spezielle Stilvorlagen für den Druck und eine andere für die Ansicht durchaus als medienneutrales Format eignen, wegen der hier eingeschränkten Möglichkeiten, gibt es eine solche Druckvorlage jedoch gar nicht, folglich wird es daher immer Kompromisse beim Ausdruck geben müssen, wobei es sicherlich ungünstig wäre, die primäre HTML-Ansicht von wikibooks zu vermuckeln - so arg ist es hier ja nicht. Wenn du in den Quelltext der Ausgabe guckst, wirst du sehen, daß die Liste nach einem Listenpunkt beendet wird, danach kommt der div-Kommentar, danach wird eine neue Liste geöffnet etc. Woran das liegt, habe ich nicht untersucht, eventuell setzt der parser ja keine Blöcke als Listenpunkte, insofern müßte man direkt die entsprechenden Elemente ul, ol, li, dl, dt, dd setzen, darin den gewünschten Inhalt mit Blöcken. Ansonsten geht es doch ungefähr in die von mir vorgeschlagene Richtung. Tabellen mit jeweils einer Tabellenzeile für den Kommentar würden ja sämtliche Struktur von Listen, Absätzen etc zerlegen. Das würde schlicht darauf hinweisen, daß man für eine Druckvorlage einfach das falsche Format verwendet, man sollte gleich mit geeigneten Programmen ein fertiges postscript oder PDF als Druckvorlage produzieren, darin gibt es bloß noch graphische Elemente, welche irgendwie angeordnet sind, ähnlich wie bei SVG, bloß im Bedarfsfalle auf mehrere Druckseiten verteilt. Eventuell ist ja auch einfach die Vorstellung über wikibooks falsch oder das Konzept, die Vorstellung über das, was hier technisch sinnvoll umsetzbar ist? LaTex-Dokumente könnte man ja zum Beispiel auch gemeinsam bei gihub basteln. Den Eindruck falscher Vorstellungen habe ich bei einigen Ideen, welche ziemlich verkrampft irgendwann mal in Vorlagen gepreßt wurden, welche später eben Markierungssuppe produzieren, was teilweise an den bescheidenen Möglichkeiten hier liegt. Die Idee von dem wiki ist eben ein minimalistischer Ansatz, entsprechend eskaliert das Drama schnell, wenn Ansprüche gestellt werden, welche dem Ansatz nicht mehr gerecht werden, komplexe Vorlage kaschieren dies allenfalls für andere naive Anwender, welche alsdann mit den Vorlagen wieder ein Pseudoformat zu lernen beginnen, was schnell zu kuriosen Ergebnissen in der Ausgabe führt, wenn sie beginnen, damit 'kreativ' umzugehen ;o) Aber ich kann um derlei Fragen im Bedarfsfalle auch ein 'PAL-Feld' legen ;o) Doktorchen 18:00, 23. Jun. 2021 (CEST)

Nun, ich sehe da im Quelltext nur eine gebrochene Liste, und die ist nicht Schuld der divs sondern des Wikiparsers. Die andere Liste hat halt nur einen Punkt. Und nach der Liste kommt auch kein Div, die kommen nach den einführenden p-tags. Woher Du den minimalistischen Ansatz des Mediawikis zu nehmen glaubst, ist mir auch nicht ganz klar. Egal, darum geht es ja hier nicht. Viele Grüße, HirnSpukDisk – 18:33, 23. Jun. 2021 (CEST)

Hinsichtlich der Listenunterbrechung - mein Fehler, da habe ich mich in der Markierungssuppe verguckt ;o) Ansonsten hat man für diese wikis ja gerade eine Art neue Auszeichnungssprache für die Eingabe entwickelt, statt einfach XHTML zu verwenden, die Idee war ja, es dadurch unkundigen Autoren einfacher zu machen, was natürlich immer weniger stimmt, je mehr Vorlagen verwendet werden, je mehr teils auch überraschende Effekte der wiki-parser liefert, welche teils auch sinnvolle Textauszeichnung unterbinden, woraus man schließen kann, daß alles von Anfang an auf einfach, teils eben zu einfach ausgerichtet war, was ja allerdings für Bücher zu den meisten Themen ausreicht. Bei den von mir betreuten Büchern bin ich ja oft auf Grenzen gestoßen, welche zeigen, daß man gewisse technische Themen besser mit eigenen Seiten im Netz behandelt. Aber genug der Abschweifung an dieser Stelle. Doktorchen 20:50, 23. Jun. 2021 (CEST)

Entschuldigt bitte die späte Rückmeldung und noch einmal ganz herzlichen Dank für euren Austausch und eure Rückmeldungen! Auch wenn ich (als Wiki-Laie) leider nicht alle eure Ausführungen untereinander verstanden hab, habe ich daraus einiges Hilfreiches ziehen können und wir haben heute nach interner Rücksprache überlegt, dass wohl der Rückgriff auf (nicht sichtbare) Tabellen für unsere Zwecke am sinnvollsten ist (am einfachsten bedienbar + wird bei richtiger Nutzung nicht in der Formatierung "zerrissen"). Dabei sind aber noch ein paar (Detail-)Fragen aufgekommen, daher vor allem @HirnSpuk:

  1. Das ist jetzt dabei herausgekommen: Lösungsskizze Ob ich die Version nehme mit linker "Korrekturspalte" oder rechter "Korrekturspalte" weiß ich noch nicht - für die Handyversion scheint die linke Spalte besser zu sein in der Anzeige. Fällt dir da auf den ersten Blick etwas Problematisches auf? Wenn ich es richtig sehe, ist das wichtigste, möglichst wenig Text pro Spalte zu haben, sodass die jeweiligen "Randbemerkungen" auch immer richtig zum entsprechenden Haupttext zugeordnet werden (egal bei welchem Anzeigeformat). Richtig?
  2. Ich hoffe, ich habe das jetzt mit der Schriftart und den Farben richtig umgesetzt, wie von dir vorgeschlagen...
  3. Kann man bei einer Tabelle irgendwie einstellen, dass NUR die Mittellinie zwischen linker und rechter Spalte (wie eine Trennlinie) sichtbar ist?
  4. Bzgl. der eingebundenen Bilder/Grafiken habe ich versucht deine Hinweise umzusetzen. Auch dort freue ich mich über Rückmeldung, falls da etwas aus deiner Sicht offenkundig "schief gelaufen" ist...
  5. Bzgl. einer der anderen beiden Seiten überlegen wir noch, ob sich möglicherweise doch dein letzter Vorschlag (hier) auch/besser für uns anbieten könnte. So richtig bin ich mir aber noch nicht sicher, wie man das gut umsetzen würde... Kann man dort einstellen wie weit rechts die "zweite Spalte" steht bzw. wie nah am Text? Mir erscheint das jedenfalls etwas komplizierter umzusetzen als die Tabelle oder? Was wären denn die Vorteile davon zur Tabelle?

In jedem Fall schonmal herzlichen Dank für die ganze Unterstützung!--Ammar Bustami 22:00, 28. Jun. 2021 (CEST)

Hallo Ammar Bustami, danke, dass Du Dich durchgekämpft hast. Ich warne allerdings vor, der folgende Text wird seeehr lang. Er ist nur leider nötig, weil wir Wünsche und Zielvorstellungen mit Gegebenheiten und Grundwissen in Deckung bringen müssen. Denn die Kurzfassung: Die simple Antwort "Macht das so, dann geht's!" kann es leider nicht geben!

Ich habe Deine Punkte oben mal durchnummeriert, um strukturiert darauf antworten zu können:

  1. Jein :)... Also,
    1. Die Bilder haben Links, die müssen raus. Bedeutet kein link= und kein verweis=, das wäre rechtlich erstmal wichtig. Wenn Du die Option setzt, aber keinen Link angibst, wird einfach gar kein Link gesetzt. Wie ich schon sagte, da die Bilder von Dir sind, ist das minderkritisch, Du verletzt damit ja nur Deine eigenen Urheberrechte ;-)
    2. Möglichst wenig Text pro Spalte ist nicht richtig. Der Text pro Spalte ist im Prinzip egal, er wird halt nur in seiner definierten Breite umgebrochen. Wichtig, generell würde ich auf <br /> verzichten, sondern lieber eine neue Tabellenzeile machen, für den nächsten Punkt. Das scheint mir aber erfüllt zu sein. Damit ist zumindest erstmal sicher gestellt, dass die/der "Korrektur/Kommentar" auf gleicher Höhe steht, die der eigentliche Text (wenn die Tabelle korrekt formatiert ist, iirc).
    3. Die Formatierung der Tabelle ist noch nicht ganz sauber, kann ich gerne mal beigehen. Siehe ganz unten. Sonst siehts soweit gut aus.
  2. Das war nur ein Vorschlag. Die Umsetzung ginge eleganter, kann ich gerne mal beigehen. Siehe ganz unten.
  3. Ja, ebenso, s.u.
  4. Siehe oben zu den "Links". Solange die Bilder unter CC-BY-SA 4.0 Lizenz auf den Wikimedia-Commons sind müssen "rein theoretisch" die Links erhalten werden, denn damit wird online und in der Weiterverwendung die Namens- und Lizenznennung bewerkstelligt. Wie ich oben allerdings sagte, aktuell müsstest Du Dich selber abmahnen ;)
  5. Wieder mal leider nur ein Jein :). Da hängen ein paar Rahmenbedingungen dran. Mehr dazu unten.

Präliminarien

Vorweg müssen wir erstmal Folgendes klären:

Ihr legt sehr viel wert auf "responsives Design" (also dass die Inhalte auf unterschiedlichen Geräten in dem Nutzer folgender Darstellung angezeigt werden). Mediawiki (also die Software, die die ganze Sache hier am Laufen hält) ist in diesem Bereich ein Hybrid, da es entstanden ist, als von responsivem Design noch nicht die Rede war und die Wikisyntax dafür quasi keinerlei Optionen bietet (Vom Visuellen Editor will ich in dem Zug gar nicht reden). Die Webseitengestaltung ist inzwischen auch eher ein Job für einen Programmierer als für einen Gestalter. Schlimmer macht die Sache der Mobilskin vom Mediawiki, der (für mich) nicht wirklich nachvollziehbar arbeitet, sodass auf dem Desktop mehr Dinge gehen, als in der mobilen Darstellung. Beschränkt man sich auf die absolute Basis-Wikisprache: =, *, #, {, -, : und Leerzeilen, dann funktioniert das noch ganz gut. Fängt man aber an Breiten zu begrenzten, große Tabellen zu benutzten oder (Gott bewahre :)) Textflüsse realisieren und oder Texte präzise nebeneinander darstellen zu wollen, wird die ganze Sache zunehmend schwierig bis unmöglich und man muss mit entsprechenden Kompromissen leben. Diese Kompromisse in der Darstellung zu erarbeiten (unterschiedliche Browser, unterschiedliche Geräte, unterschiedliche Auflösungen) macht beliebig viel Arbeit. Die Folge davon ist, dass Ihr sehr gut kontrollieren müsst, ob alles auf allen Geräten so aussieht, dass es für Euch taugt. Es wird (und kann) nicht auf allen Geräten gleich aussehen. Jetzt kommt bei Euch noch eine weitere Anforderung dazu: Ihr wollt das auch noch ausdrucken/exportieren können. (Und womöglich auch noch inklusiv Screenreader etc. nicht aus den Augen verlieren?)

Und noch eins muss von vorn herein klar sein: Eine beliebige Textverarbeitung ist an sich für die Erstellung und den Ausdruck eines größeren Werks auch quasi nur eine Krücke. Absatzabstände über Leerzeilen einzustellen, wie es Gang und Gäbe ist, ist im günstigsten Falle bloß hässlich. Zum Glück sind heutige Programme mit Formatvorlagen da recht mächtig. Wenn es aber um Textflüsse, Tabellen und Kästen geht, ist auch ein Textverarbeitungsprogramm limitiert. Und das macht die ganze Sache nur für ein einziges Ergebnis (einen vorgegebenen Seitenausdruck).

Das Mediawiki von Wikibooks soll nun also folgende Funktionalitäten bereit stellen:

  • Eine Website bauen (Designer, Programmierer)
  • Ein Buch schreiben (Autor, Setzer, Drucker)
  • Ein Buch lesen (Kunde mit Erwartungshaltung)
  • Auf unterschiedlichen Geräten und im Ausdruck vernünftig aussehen (quasi so, als würdet Ihr ein Buch in 7 verschiedenen Formaten raus bringen: A4, A5, A6, jeweils in Farbe und Schwarz/Weiß und bei der letzten Ausgabe sollen auch noch Reliefs geprägt werden.)
  • kollaborativ das alles tun (alle sollen da jederzeit alles dran tun können auch gleichzeitig)
  • und die Leute, die das bedienen, sollen das mit so wenig Vorkenntnissen, wie nur irgendmöglich machen. (ohne die Fachausbildung des jeweiligen Fachs (Drucker, Designer...) zu haben)

Da von Euch schon andernorts der Kommentar kam: "Aber die Leute sind das viel einfacher gewohnt!" in diesem Zusammenhang eine Frage: Habt Ihr in Kommentarspalten von Sozialen Medien schonmal die Möglichkeit gesehen, die Kommentare anderer Nutzer gestalterisch gezielt kommentieren und verbessern zu können?

Das alles ist eine Herausforderung, die nicht einfach zu bewältigen ist. Mit der radikalen Editierbarkeit, dem Webspace, der Systemverwaltung und Pflege ist schonmal jede Menge erledigt. Das geht aber nur zu einem gewissen Preis (allen voran die Wikisyntax, statt sich auch noch mit den Seitenstylings rumschlagen zu müssen).

Um wirklich alles abdecken zu können (wenn das überhaupt möglich ist) bräuchte es von Eurer Seite vermutlich einen Programmierer/Designer, am besten mit tieferen Kenntnissen in Webseitengestaltung, CSS, Javascript und idealerweise in LUA und im Mediawiki. Darüber hinaus muss das dann aber auch alles im Gemeinschaftsrahmen der Wikimedia ablaufen.

Läuft also alles darauf hinaus: Mit wie vielen Kompromissen können wir Leben? In diesem speziellen Fall: Muss das wirklich präzise links vom Text angezeigt werden? Muss der Abstand wirklich einstellbar sein? Muss das wirklich eine bestimmte Auszeichnung haben und wenn ja, welche?

Konkreter Rat

(Alles unter der Bedingung, dass ich mich mit dem visuellen Editor überhaupt nicht auskenne)

  • Mein erster Vorschlag ist für den Ausdruck nicht sinnvoll.
  • Mein zweiter Vorschlag ist für den Ablauf und die Gesamtgestaltung nicht sinnvoll
  • Mein dritter ("letzter") Vorschlag erweckt den Eindruck von Spalten, das ist so nicht richtig, siehe den letzten Punkt dieser Liste.
  • Wenn Ihr die Darstellung zwingend immer exakt nebeneinander haben wollt (wovon ich wegen unten genannter Nachteile wärmstens abrate), dann ist in meinen Augen die Tabelle für Euch die beste Lösung. Als nächstes müsste nun eine Formatierung gefunden werden, die Euch in so vielen gewünschten Medien wie möglich die gewünschte Ausgabe erzeugt und in der Benutzung Euren Wünschen am besten entgegen kommt.
    • Vorteil (?): Die Tabelle ist im Visuellen Editor ohne Vorlagengeraffel editierbar und stellt das gewünschte Format bereit.
    • Nachteil(e):
      • Die Formatierung muss (vermutlich?) je Tabelle im Quelltext korrekt gesetzt werden (sonst entsteht intern als Quelltext der Webseite das, was Doktorchen oben "Formatierungssuppe" genannt hat). Hier könnte man möglicherweise über eine Vorlage helfend eingreifen. Die Verwendung ist aber durch die Notwendigkeit von subst komplizierter als sonst bei Vorlagen. Dafür muss man aber vermutlich nur eine Vorlage verwenden.
      • Das auf beliebigen Geräten in einer Art hin zu bekommen, dass es vernünftig aussieht ist in meinen Augen seeeehr schwierig. Im schlimmsten Fall steht man mit zwei Tabellenspalten da, wo in der einen pro Zeile nur ein Wort dargestellt wird, obwohl ein längerer Text da steht (ein bisschen so, wie in meinem letzten Beispiel, wo ich das gezielt provoziert habe).
      • Screenreader werden damit möglicherweise Schwierigkeiten haben. Vermutlich mindestens in der sinnvollen Interpretation, denn da wo wir Menschen eine Korrekturspalte wahrnehmen, erkennt der Screenreader ja nur den ersten Inhalt. Da wird es mit dem semantischen Zusammenhang dann schwierig (ich will nicht ausschließen, dass es da dann nicht auch Lösungen für geben könnte. Ich bin leider weder Designer, Programmierer noch Setzer).
      • Ihr müsstet überprüfen, wie das im Export aussieht und hier ggf. (so vermute ich) inhaltlich nacharbeiten.
  • Ich empfehle meinen "letzten Vorschlag" (der in gewisser Weise eine "brauchbare" Version von meinem ersten und zweiten ist)
    • Vorteile:
      • Per Vorlagen bedien- und konfigurierbar
      • klar einer Seitenstelle zuzuordnen (Stichwort Semantik)
      • Wahrscheinlich deutlich "responsiver" als die Tabellenlösung, man könnte auf entsprechend schmalen Geräten den Abschnitt dann unter den Abschnitt setzen, auf den sich bezogen wird. Damit vermeidet man Umbruchsprobleme.
      • Arbeiten am Haupttext finden ganz normal statt.(s. u. Viele Grüße, HirnSpukDisk – 11:58, 30. Jun. 2021 (CEST))
    • Nachteile:
      • Keine strikte Trennung der beiden Spalten, Wirkung kann wie rechts oder links platzierte Kästen sein
      • Der Abstand zwischen den beiden Inhalten ist zwar konfigurierbar, aber nicht beliebig und mit der Bedingung der Darstellbarkeit auf verschiedenen Geräten muss er sich ändern können dürfen.

Ich empfehle also eine Vorlage der Art, wie oben bereits vorgeschlagen: {{Korrigieren}}Irgendein Text, der zu korrigieren wäre,... {{Korrektur|Rot|[[Datei:Blitz1.png|15px|links]]Dies wäre dann eine Korrektur des neben oder drüber stehenden Absatzes. Das Styling ließe sich über entsprechende Vorlagen-Optionen anpassen. Es entsteht ein fliegender Kasten, der bei entsprechender Darstellung unter den Absatz "rutscht".}} Mit noch einer Vorlage mehr könnte man vielleicht sogar den Korrekturinhalt editierbar machen. Ob das im Visual Editor funktioniert bliebe auszuprobieren. Evtl. lässt sich das auch so realisieren, dass man links oder rechts wählen kann. (Anm.: Hier im Quelltext natürlich noch nicht als Vorlage umgesetzt, sondern erstmal roh, falls Du rein gucken solltest.)

Blitz1.png
Dies wäre dann eine Korrektur des neben oder drüber stehenden Absatzes. Das Styling ließe sich über entsprechende Vorlagen-Optionen anpassen. Es entsteht ein fliegender Kasten, der bei entsprechender Darstellung unter den Absatz "rutscht".

Oder andersrum:

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Blitz1.png
Dies wäre dann eine Korrektur des neben oder drüber stehenden Absatzes. Das Styling ließe sich über entsprechende Vorlagen-Optionen anpassen. Es entsteht ein fliegender Kasten, der bei entsprechender Darstellung unter den Absatz "rutscht".

Das ganze geht alles ohne Gewähr von meinem aktuellen Stand der Kenntnis. So... Nun: Welches Schweinderl hättens denn gerne :-D? Ich kann gern nochmal über den Quelltext drüber gucken, oder eine entsprechende Vorlage bauen. Allerdings mache ich das nur, wenn wirklich geklärt ist, wie es laufen soll. Meinetwegen auch in beiden Lösungen. Wenn das soweit ist und nochmal tiefere Hilfe benötigt wird, dann sag mir, wann ich wo gucken soll und editieren kann. Dann starte ich mal einen Versuch die gewünschten Ergebnisse zu erzeugen oder zu verbessern (Stichwort eleganter, Tabellenlinie, etc.).

Viele Grüße, HirnSpukDisk – 16:50, 29. Jun. 2021 (CEST)

Die CSS-Arbeitsgruppe hat da auch noch ein neues Modul in Vorbereitung für ähnliche Zwecke: Grid Layout, geht also schon prinzipiell oder in Zukunft mit (X)HTML+CSS sowie sinnvoller semantischer Struktur des Inhaltes, bloß eben nicht mit Grundlage des wiki-Systems. Auch sonst läßt sich allerhand mit absoluter Positionierung graphisch zuordnen, mit Einheiten wie em, ex lassen sich auch Breiten und Höhen solide angeben, eventuell muß man dann allerdings auf eine feste Seitenbreite setzen, das Publikum muß also wieder horizontal rollen oder skalieren, ähnlich wie bei PDF. Eine inhaltliche Zuordnung beliebiger Blöcke ist hingegen kniffliger, bei Korrekturen eben mit del und ins, sonst mit gegenseitigen Verweisen, eventuell auch zusätzlichen verschiedenen Dokumenten (iframe?). Bleibt eben dabei, wie man es auch dreht, will man präzise festlegen, was wo stehen soll, wie Abschnitte einander graphisch zugeordnet werden werden sollen, landet man immer bei irgendwas wie Vektorgraphik. Der (X)HTML-Quelltext hat sowieso immer eine lineare Abfolge von Inhalten, woran nichts zu ändern ist. Mit dem einfachen wiki-System bringt man sich fast automatisch in Schwierigkeiten, wenn man gestalterisch davon stark abweicht, ist eben doch eher für Bücher geeignet, welche dieser linearen Anordnung von Inhalten folgen wollen, was ja auch wirklich die allermeisten sind. Bei den anderen wird man automatisch ohne Kenntnisse der verwendeten Formate kaum anständig durchkommen ... Doktorchen 17:55, 29. Jun. 2021 (CEST)

Hallo Ammar Bustami, ich habe jetzt mal probiert, denn ich denke die Funktionalität könnte öfter gebraucht werden und eine Wikibooks-weite Vorlage von Vorteil sein.

Ich habe eine gute und eine schlechte Nachricht:

  • Die schlechte: Leider funktioniert die Bearbeitung im visuellen Editor nicht, wie ich es mir vorgestellt habe.
  • Die gute: man braucht nur eine Vorlage und im Inhalt kann man durchaus Wikiquelltext benutzen und so Formatierungen erreichen. Wenn also Absatzformatierungen gewünscht wären, dann müsste ein bisschen Wikiquelltext schon verwendet werden. Mein Spielbeispiel gibts dort zu sehen: Benutzer:HirnSpuk/Werkstatt/01. Die Abschnitte zwischen den <noinclude>-Tags sind das Anwendungsbeispiel von Euch. Spiel ruhig damit, wenn Du willst, kaputt machen kannst Du nichts. Falls Du Dir das mal mit rechtsbündigen Kommentaren ansehen willst (find ich auch gar nicht schlecht), machst Du dort oben aus dem <div style="float: left; width: 30%; [...] 2px solid lightgrey;"> ein <div style="float: left; width: 30%; [...] 2px solid lightgrey; text-align: right;">.

Schaus Dir mal an und meld Dich. Viele Grüße, HirnSpukDisk – 11:58, 30. Jun. 2021 (CEST)

Rückmeldung zur Auswahl[Bearbeiten]

Lieber @HirnSpuk, danke dir für die ernut sehr hilfreichen und ausführlichen Rückmeldungen - insbesondere zu den Anforderungen und erwartbaren Leistungen von Wikibooks!

Was deinen konkreten Rat angeht, haben wir uns jetzt in Rücksprache untereinander und vor allem auch mit Blick auf die für uns am einfachsten und mit am wenigsten Aufwand durchführbare Variante entschieden: nämlich doch beim Tabellenformat zu bleiben. Dabei habe ich jetzt ein ganz schlechtes Gewissen, dass du dir jetzt extra die Mühe gemacht hast, eine neue Vorlage für uns zu basteln. Die sieht auch ganz cool aus und ich wüsste letztlich gar nicht, was mir besser gefällt. Letztlich ist bei uns allen momentan aber die Zeit so knapp (auch mit einer anstehenden Frist), dass ich mir jetzt leider nicht zutraue, mich nochmal ausreichend damit zu beschäftigen, um alles auf die neue Vorlage umzustellen. Und auch für die anderen ist es deutlich einfacher, mit dem visuellen Editor arbeiten zu können. Letztlich haben wir uns jetzt auch überlegt, dass wir mit der Tabellenformatierung - soweit wir das sehen - ausreichend "responsiv" unterwegs sind, bzw. uns das in dem Sinn jetzt doch ausreicht. Wenn wir so wie von dir vorschlagen einfach nicht zu viel Text pro Tabellenzeile verwenden, passt das so ja eigentlich.

Auf meiner Seite habe ich das jetzt auch so weitestgehend umgesetzt. Wenn dein Angebot noch steht, da nochmal abschließend über den Quelltext zu schauen, dann würde das uns sehr freuen. =) Wenn ich dich richtig verstanden hatte, wären das dann ja v.a. die folgenden Aspekte:

  1. Ergänzung der mittleren Tabellenlinie zwischen den Spalten
  2. evtl. Formatierungsfehler beheben
  3. Fehler bei der Bildeinbindung? (ich hoffe ich habe dich jetzt richtig verstanden bei der Nichteinfügung der Links)
  4. Nicht wundern: Wir haben uns bei der Schriftart jetzt doch gegen eine eigene entschieden und stattdessen "nur" für bunte Kursivschrift in der rechten Spalte. Da habe ich jetzt wieder den folgenden Quelltext genutzt: Beispiel - einfach weil ich nicht wusste, wie das einfacher geht.
  5. Unklar ist mir ehrlich gesagt noch, wieso die rechte Spalte bei der Tabelle zur Zulässigkeit an anderer Stelle ansetzt, also nicht bündig ist, mit der Tabelle zur Begründetheit. Erkennst du da vielleicht meinen Fehler?

Ich hoffe, dass du unsere Entscheidung für das Tabellenformat nachvollziehen kannst. Und nochmal riesiges Dankeschön für deine bisherige Unterstützung! --Ammar Bustami 18:04, 1. Jul. 2021 (CEST)

Hallo Ammar, kein Problem. Ist erledigt. Schlechtes Gewissen brauchst Du nicht haben. Ich hab was gelernt :). Dort bekommst Du angezeigt, was ich geändert habe: Spezial:Diff/965490/965520.

  1. erledigt
  2. Das sind keine "Fehler" in dem Sinne, es wär halt nur ein wenig eleganter gegangen. Aber aus Gründen der Konsistenz habe ich es jetzt so gelassen.
  3. Die Bilder hab ich gerade gezogen
  4. Alles gut. Kann man so machen.
  5. Das geschieht wegen der Breite der Bilder. Die Bilder "überschreiben" quasi die Breitendefinition der Tabelle. Ich habe die Bilder jetzt alle auf eine Breite von 250px eingestellt, damit sind sie innerhalb der Prozent-Skalierung der Tabelle.

Ein Hinweis noch: Die Korrekturen könnten für Farbsehgeschwächte ein ernstes Problem sein :). Fühl Dich frei zurückzusetzen, was nicht gefällt; schau Dir an, was ich gemacht habe; bei Fragen fragen. Viele Grüße, HirnSpukDisk – 20:48, 1. Jul. 2021 (CEST)


(abschließende) Nachfragen[Bearbeiten]

Lieber @HirnSpuk, entschuldige die späte Rückmeldung! Und vielen Dank für das "Geradebügeln"! =) Vielleicht darf ich nochmal ein paar (hoffentlich) abschließende Nachfragen dranhängen:

  1. Ich war jetzt bzgl. der Bilder nochmal verwirrt. Du hast es jetzt ja so "gerade gezogen", dass wenn man auf die Grafik klickt, einem diese in Groß (mit Beschreibung der Bildseite etc.) angezeigt wird. Das hatte ich ja gerade vermeiden wollen, also dass man bestens gar nicht auf die Grafik klicken kann. Ich dachte, das war der Weg mit dem "mein eigenes Urheberrecht verletzen" - war das nicht richtig wie ursprünglich mit der Ergänzung "link="?
  2. Könntest du auch über diese Tabelle nochmal drüber schauen, ob es da etwas "gerade zu bügeln" gibt?
  3. Genauso gerne über diese Tabelle mit deutlich mehr Inhalten in der "Korrekturspalte" sowie einer zusätzlichen eingefügten 3. Spalte zur Punktevergabe?
  4. Und schließlich noch eine andere Formatierungsfrage, die mit den ganzen Tabellen gar nichts zu tun hat: Kann man irgendwie in dem hier im Klausurtaktik-Kasten eingefügten Prüfungsschema die zweite Gliederungsebene (z.B. 1. Berührt die Tätigkeit/gesellschaftliche Entwicklung den Schutzbereich des Grundrechts?) so formatieren, dass dort nicht 1. und 2. steht, sondern a und b?

Auch wenn du das jetzt nicht mehr schaffst, ist das natürlich überhaupt kein Problem und völlig verständlich! In jedem Fall noch einmal riesiges Dankeschön für deine bisherige Unterstützung! --Ammar Bustami 15:49, 28. Jul. 2021 (CEST)

Hallo Ammar,

  1. Wenn es Dir tatsächlich darauf ankommt, die Bilder explizit nicht zu verlinken, dann ist "link=" schon korrekt. Du solltest Dich nur nicht daran gewöhnen, denn nach den Richtlinien der Commons ist der Link nötig um der Lizenz genüge zu tun (vgl. c:Special:Permanentlink/559354101#Question_about_licensing_–_fulfilling_different_licensing_requirements). Es käme auf einen Präzedenzfall an. Ich weiß nicht, ob ein unbeteiligter Dritter die Wikimedia-DE verklagen könnte, weil Lizenzvereinbarungen nicht eingehalten werden (Du selbst willst das offensichtlich nicht ;-)).
  2. sieht auf den schnellen Blick in Ordnung aus.
  3. Sei mir nicht böse, aber das ist mir dann doch etwas zu viel das komplett durchzugehen.
    • Ein Fehler ist drin: Du legst drei Tabellen-Spalten an, definierst aber nur die Breite von zweien.
    • Ich würde es grundsätzlich etwas anders machen, das habe ich Dir mal beispielhaft an ein paar Zeilen und etwas komplexeren Ecken umgesetzt, vgl Spezial:Diff/prev/967299. Wenns Dir nicht gefällt setz es zurück. Dann solltest Du aber für die dritte Spalte eine ordentliche Breitendefinition setzen. Ein Mobil-Überprüfung stünde auch noch aus.
  4. done, so richtig?

Gern geschehen, Viele Grüße, HirnSpukDisk – 17:37, 28. Jul. 2021 (CEST)

Umfrage startet![Bearbeiten]

Wikibooks-logo.svg
Bitte nimm an der Umfrage zur zukünftigen Gestaltung der deutschen Wikibooks teil. Die Umfrage läuft mindestens bis zum 1. September 2021, 0:00 CEST (abhängig von Zeit und Motivation der Helfenden. Vielen Dank an dieser Stelle!). Beiträge, die danach eingehen können wahrscheinlich nicht mehr berücksichtigt werden. Die Umfrage hat 75 Fragen und dauert ungefähr 40 Minuten.
Hier geht's zur UmfrageInformationen zur UmfrageAntworten Anderer auf die UmfrageAuswertung der Umfrage

Die Umfrage kann auch in 5 Einzelteilen durchgeführt werden (sinnvollerweise in Reihenfolge):

Teil 1 • Nutzungsgewohnheiten (~5 min.) × Teil 2 • Details zur Nutzung (~10 min.) × Teil 3 • Zu Inhalten (~10 min.) ×

Teil 4 • Zur Gemeinschaft (~10 min.) × Teil 5 • Rahmenbedingungen (~5 min.)
Danke für die HilfeHirnSpuk

Anm.: Ping an die Administratoren, die sich bereit erklärt haben, @Benutzer:Stephan Kulla, Benutzer:Klaus Eifert, Benutzer:Yomomo; Danke für Eure Hilfsbereitschaft. Schaltet die Banner, wie Ihr es für richtig haltet. Wenn Ihr meiner Idee und meinem Plan folgen möchtet, würde das erste Banner am 1. August geschaltet werden. Viele Grüße, HirnSpukDisk – 01:43, 15. Jul. 2021 (CEST)

passt, mach ich dann! LG! Yomomo 17:26, 15. Jul. 2021 (CEST)
Da bereits 7 Antworten da sind (herzlichen Dank an alle bisherigen Teilnehmer:innen), ist mein Plan der Banner-Eskalation hinfällig. Um einen anderen Vorschlag zu machen: Ich würde nur noch die beiden ersten benutzen. Viele Grüße, HirnSpukDisk – 12:15, 25. Jul. 2021 (CEST)