Wikibooks:Ich brauche Hilfe

Aus Wikibooks
Wechseln zu: Navigation, Suche

Häufig gestellte Fragen · Ich brauche Hilfe · Meinungsbilder · Verbesserungsvorschläge
Review · Rundschau · Schwarzes Brett · Bots  · Wikiquette · Wunschzettel · Import
Crystal Clear app wp.png
Abkürzung:
WB:IBH
Willkommen
Nuvola apps filetypes.png

Du hast Fragen über Wikibooks? Hier kannst du sie stellen, wenn sie noch nicht in den FAQ oder im Wikibooks-Lehrbuch beantwortet wurden. Allerdings solltest du beachten, das dieses Projekt noch relativ jung und die Anzahl der Mitarbeiter noch gering ist.
Wenn deine Frage nicht sofort beantwortet wird, hab ein wenig Geduld. Was nicht hierher gehört, sondern wofür es eigene Seiten gibt:

Wohin du deine Diskussionsbeiträge platzieren kannst, steht in Diskussionsseiten benutzen.
Vielleicht ist deine Frage schon im Wikibooks-Lehrbuch beantwortet worden. Wenn nicht, setze sie bitte auch auf die Wunschliste für Hilfethemen
Ältere Fragen finden sich in den Archiven: 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011.
Hier stellst du deine Frage

Dabei bitte beachten:

  • aussagekräftigen Betreff wählen
  • Unterschreibe mit -- ~~~~.
  • Bei Fragen zu einem bestimmten Kapitel immer [[verlinken]]

Bei Fragestellung über die Bearbeiten-Funktion:

  • Neue Fragen bitte immer an das Ende des Textes setzen und mit einer neuen ==Überschrift== beginnen.

Bitte aber beachten: Wikibookianer helfen gern - aber wir sind kein kostenloser Recherche- oder Auskunftsdienst. Dafür gibt es Wikipedia:Auskunft. Diese Seite ist für Fragen rund um die Wikibooks gedacht.

Fragen werden ins Archiv verschoben, wenn sie abschließend behandelt wurden – entweder ausdrücklich oder implizit. Für etwa drei Monate wird am Anfang im Abschnitt Kürzlich archivierte Themen noch darauf hingewiesen. Für das Verfahren der Archivierung stehen die Vorlage:Archiv Hilfe (mit Arbeitsanleitung) sowie Vorlage:Archiv Hinweis zur Verfügung.

Hilfe: Erste Schritte | FAQ | Kommunikation: Chat
Hilfe

Inhaltsverzeichnis

[Bearbeiten] Kürzlich archivierte Themen

Alte Themen mit Antworten wurden archiviert, auch wenn sie nicht ausdrücklich als "erledigt" gekennzeichnet sind. Fragen ohne Antworten werden nicht archivert.
Letzte Archivierung durch Jürgen 16:18, 19. Dez. 2011 (CET)

[Bearbeiten] {{clear}}-Funktion bei PDF Druckversion

Leider funktioniert die {{clear}}-Funktion bei der automatischen Druckversion nicht... :/ Kann dies jemand beheben? --Schoggi 17:17, 17. Jul. 2010 (CEST)

[Bearbeiten] Bildgröße bei Thumbnails und Galerien sehr unterschiedlich

Ich habe gerade eine Diskrepanz bei der Darstellung von Bildern festgestellt. Genauer: Es ist mir schon länger aufgefallen, aber jetzt wollte ich untersuchen, warum die Galerie-Bilder immer so winzig aussehen und was man machen könnte. Beispiel:

Der Canale Grande in Venedig.

  • Der Canale Grande in Venedig.

  • Der Canale Grande in Venedig.

In allen Fällen wird eine Breite von 200px vorgegeben. In der letzten Version ist zusätzlich eine Höhe angegeben entsprechend einem Hinweis in der Wikipedia-Hilfe unter Fehlerhafte Gallery-Darstellung. Aber die Hauptfrage nach dem überflüssigen Freiraum wird doch auch nicht geklärt. Außerdem kann ich doch nicht jedesmal die Höhe nach dem Seitenverhältnis ausrechnen und festlegen; und was wird, wenn unterschiedlich gestaltete Bilder in einer gemeinsamen Galerie landen sollen?

[[Datei:Canal_Grande_in_Venice.JPG|thumb|200px|left|Der Canale Grande in Venedig.]]
<gallery widths="200px">Datei:Canal_Grande_in_Venice.JPG|Der Canale Grande in Venedig.</gallery>
<gallery widths="200px" heights="150" class="float-left">Datei:Canal_Grande_in_Venice.JPG|Der Canale Grande in Venedig.</gallery>

Ich hätte erwartet, dass bei der Galerie das Bild an die festgelegte Größe angepasst und der innere Rahmen vollständig ausgefüllt werden würde. Meine Vermutung ist, dass in einer css-Datei das <gallery>-Tag einen unpassenden Padding-Parameter enthält. Tatsächlich werden in Wikipedia:Verbesserungsvorschläge Padding-Werte von 20px und 31px angezeigt. Dort wird auch noch auf Commons:MediaWiki:ResizeGalleries.js verwiesen.

Ich habe aber keine Ahnung, wo und wie das Problem generell gelöst werden könnte. Ich finde auch keine Stelle, wo das eigentlich festgelegt ist. Kann mir jemand helfen? Die Suchfunktion der Wikipedia liefert für "gallery" Tausende von Treffern, aber vorzugsweise Galerien, außerdem Hinweise zur Nutzung des <gallery>-Tags, aber so gut wie nichts zu seiner Definition. -- Danke! Jürgen 12:55, 14. Sep. 2010 (CEST)

[Bearbeiten] Artikel für Wikimedia Deutschland Informationsbroschüren

Ich wurde gebeten, einen Artikel für die Wikimedia zu schreiben. Ob ich die Zeit finde, einen Artikel zu schreiben, weiß ich nicht, jedoch ihr könntet mir mithelfen, und vielleicht einen Satz oder einen Abschnitt mit dazu beitragen. Setzt einfach auf meiner Seite Benutzer:Mjchael/ Brainstorming eure Ideen rein. Sie müssen nicht zum Text passen, denn es handelt sich vorerst nur um eine Quellensammlung. Brainstorming eben. Wenn einiges zusammenkommt, kann es dann ins Reine geschreiben werden. Gruß --mjchael 23:27, 7. Jun. 2011 (CEST)

[Bearbeiten] Infobroschüre Wikibooks

Hallo! Mjchael hat mir den Tipp gegeben, hier mal anzuklopfen. Ich plane für Wikimedia Deutschland eine Infobroschüre über Wikibooks zu erstellen und würde mich über fachkundige Hilfe freuen. Erste Details habe ich auf meiner Benutzerseite hinterlegt. Wie die Reihe mit bisher erschienen Broschüren aussieht, findet ihre übrigens auf der WMDE-Webseite. Über eure Kommentare würde ich mehr sehr freuen! Viele Grüße, --Michael Jahn WMDE 15:12, 14. Jul. 2011 (CEST)

[Bearbeiten] Breite des Inhaltsverzeichnisses ändern

Hallo Leute,

ich bin gerade dabei die Vorlage Aufgabensammlung: Vorlage:Infobox zu programmieren. Hier habe ich Probleme mit dem Inhaltsverzeichnis, der in die Infobox aufgenommen werden soll (siehe Beispiel auf der Vorlagenseite ganz unten). Ich müsste nämlich die Breite des Inhaltsverzeichnis irgendwie steuern können. Kennt ihr da eine Möglichkeit? Eine andere Lösung für mich wäre es, wenn man das Inhaltsverzeichnis ohne Rahmen darstellen könnte. Geht das irgendwie? Grüße Chuck 16:00, 20. Sep. 2011 (CEST)

und im style 
style="{{#if:{{{width}}}|width:{{{width}}}em;|}}"
die Breite anzugeben hilft nicht weiter? -- ThePacker 16:15, 20. Sep. 2011 (CEST)
Ich habe das Inhaltsverzeichnis mit __TOC__ eingebunden. Dieses erzeugt ein <div class="toc">...</div>. Die Breite und der Rahmen des Inhaltsverzeichnisses ist in der CSS-Klasse toc definiert, auf den ich direkt keinen Einfluss habe. Ich bräuchte also eine Möglichkeit die in der CSS-Klasse toc definierten Eigenschaften zu überschreiben. Grüße Chuck 16:27, 20. Sep. 2011 (CEST)
Hmm, dann wirds schwieriger. Eigentlich besteht dann die sinnvollste Lösung darin, das mit Javascript zu machen. und das Toc an ein "übergeordnetes" Div anzupassen. -- ThePacker 16:48, 20. Sep. 2011 (CEST)
Vielleicht hilft die Vorlage:TOCright mit einem Rahmen in einer Tabelle im Rahmen. Es entspricht zwar nicht deinem Plan, weil es auf __TOC__ zurückgreift; aber vielleicht kannst du daraus eine Idee für deine Infobox ableiten. -- Gruß Jürgen 16:59, 20. Sep. 2011 (CEST)
Danke für den Tipp. Leider hilft mir Vorlage:TOCright nicht weiter (hier bekomme ich dasselbe Problem). Ich habe aber gesehen, dass es in der deutschsprachigen Wikipedia eine CSS-Klasse toclimit-<Nummer> mit der die Darstellung der Überschriften bis zu Ebene <Nummer> eingestellt werden kann. Mir kam die Idee eine CSS-Klasse toc-noborder mit folgender Definition einzuführen:
.toc-noborder .toc, .toc-noborder #toc { border: none; }
Durch den Code <div class="toc-noborder">__TOC__</div> könnte man dann das Inhaltsverzeichnis ohne Rahmen darstellen. Dies wäre eine mögliche Lösung des Problems, bedarf aber einer Anpassung von MediaWiki:Common.css. Können wir dies machen? Grüße Chuck 17:23, 20. Sep. 2011 (CEST)
Im Prinzip schon, Ich würde mich im Laufe der Woche darum kümmern. Wäre das Okay für Dich? -- ThePacker 17:39, 20. Sep. 2011 (CEST)
In Ordnung. Vielen Dank. Grüße Chuck 17:53, 20. Sep. 2011 (CEST)

Hallo Leute,

habe in den nächsten Wochen mal wieder mehr Zeit für Wikibooks. Wie sieht es mit den Änderungen in MediaWiki:Common.css aus? Ich konnte keine neue CSS-Klasse .toc-noborder entdecken. Grüße Chuck 18:08, 11. Feb. 2012 (CET)

[Bearbeiten] Lokales Wiki einrichten

Wie an anderer Stelle erwähnt, befasse ich mich damit, ein lokales Wiki einzurichten. Auf der Grundlage von MoWeS Portable ist das erstaunlich einfach, auch wenn MediaWiki manuell hinzugefügt werden muss (MoWeS bietet Version 1.16 an, bei WMF läuft 1.18). Auch die Extensions, Bücher und Vorlagen sowie Commons-Dateien lassen sich (fast) problemlos einbinden. Für die folgenden Einzelthemen benötige ich aber Unterstützung.

Arbeitsumgebung:

  • Windows 7 Home Premium (4 GB RAM), Firefox 8.0
  • MoWeS Portable 2, Apache HTTP Server (2.2.11), ImageMagick (Version 4.2.9), MySQL (Version 5.5.8), PHP5 (Version 5.3.5), PHPMyAdmin (Version 3.3.9)
  • MediaWiki 1.18.0 mit etwa 30 Extensions

Weitere konkrete Fragen werde ich in der Arbeitsanleitung ansprechen, wenn es soweit ist. -- Jürgen 10:06, 20. Dez. 2011 (CET)

[Bearbeiten] Cache oder DB-Einstellungen

Der Zugriff auf die lokale MySQL-Datenbank ist katastrophal langsam. Das sollte sich mit Cache oder mit DB-Einstellungen deutlich verbessern lassen, aber wie? In LocalSettings.php steht nichts Geeignetes zu MySQL. In my.ini für MySQL finde ich die folgenden Einträge; kann man damit etwas verbessern?

# Note: In case your tables change very often or if your queries are
# textually different every time, the query cache may result in a
# slowdown instead of a performance improvement.
query_cache_size=0
thread_cache_size=8
innodb_buffer_pool_size=8M   # InnoDB ist aktiviert

Cache ist bisher nicht aktiviert. Bei der MW-Installation wird geprüft, ob einer der folgenden PHP-Caches installiert ist (bei mir bisher keiner, siehe Anmerkungen):

  • eAccelerator – kann nur manuell erstellt werden auf der Grundlage des gesamten Quelltexts von PHP zusammen mit dem Visual Studio C-Compiler
    Dafür fehlen mir die Kenntnisse; außerdem geht es um eine einfache Installation, und da darf man nicht erst eine DLL erstellen müssen.
  • APC – ähnliche Situation: Eine DLL-Datei für diese PECL-Erweiterung steht derzeit nicht zur Verfügung. Weitere Details finden Sie im Abschnitt zum Kompilieren für Windows.
  • WinCache – verlangt MS-Web Platform Installer oder PEAR Installer. Beide Anforderungen widersprechen meiner Forderung nach einer einfachen Installation.
  • XCache – bietet einfache Installation an, aber mit einer großen Anzahl von Versionen.

Ich habe XCache probiert mit der Version XCache-1.3.2-php-5.3.6-Win32-VC9-x86.zip (wegen der PHP-Version), bin mir aber sehr unsicher, ob nicht eine andere Version richtig wäre. Auch ist die Installationsbeschreibung (siehe o.g. Link) sehr vage: Read xcache.ini and modify... Was hilft es mir, die xcache.ini zu lesen? Welche der dort genannten Einstellungen sind relevant? Es genügt jedenfalls nicht, in der php.ini den Eintrag extension=php_xcache.dll einzufügen; und wo gehört set xcache.size hin mit welchem Wert?

Außerdem: Wie können PHP und MediaWiki die nachträgliche Installation des Cache erkennen? Genügt der Eintrag in LocalSettings mit CacheType "Anything"? -- Jürgen 10:06, 20. Dez. 2011 (CET)

[Bearbeiten] Interwiki-Links

Einfache Links mit [...] zeigen auf das richtige Ziel im Internet. Interwiki-Links im lokalen Wiki verweisen aber auf "localhost" und sind deshalb "rot". Gibt es eine Möglichkeit, diese auf das Internet umzuleiten nach [http://de.wikipedia.org/wiki/...]? Ich könnte mir vorstellen, dass es mit einem ähnlichen Verfahren wie im nächsten Abschnitt geht oder mit einer Extension, die standardmäßig zur Verfügung steht, aber weder in der Installationsroutine noch in Spezial:Version erwähnt ist. -- Jürgen 10:06, 20. Dez. 2011 (CET)

Guck mal auf mw:Manual:Interwiki. Dort werden Interwikis beschrieben. Unter mw:Category:Interwiki extensions findest du Extensions, mit denen du Interwikis ändern kannst. Du kannst aber natürlich auch maintenance/dumpInterwiki.php ändern ... ;) -- heuler06 17:05, 20. Dez. 2011 (CET)
Danke, das sind ein paar nützliche Hinweise. Ich werde mich mal durcharbeiten. maintenance/dumpInterwiki.php werde ich wohl kaum ändern (deshalb hattest du ja auch das Smiley angehängt) ohne PHP-Kenntnisse und im Sinne einer einfachen Installation für alle; aber es sollte etwas herauskommen. -- Jürgen 17:46, 20. Dez. 2011 (CET)
Nach Lektüre der verschiedenen Extensions und Beschreibungen und mehreren Versuchen habe ich eine Ahnung davon bekommen, wo und wie die Präfixe gespeichert werden, auch wenn ich noch nicht verstehe, an welcher Stelle der Installation (gemeint ist das Setup) die Datensätze in der Datenbank gespeichert und wie die Präfixe interpretiert werden. Da es mir um eine automatische, aber dennoch flexible Installation für verschiedene Zwecke geht, habe ich mich zu folgendem Verfahren entschieden:
  • Die Installation selbst wird nicht angepasst; auf die zusätzlich gewünschten Interwiki-Links wird zunächst verzichtet.
  • Genauso, wie in der MW-Installation unter maintenance eine wikipedia-interwiki.sql enthalten ist, stelle ich wikibooks-interwiki.sql sowie wikibooks-interwiki-de.sql zur Verfügung.
  • Wenn jemand wie ich die direkten Links nach WB und WP haben möchte, kann er mit phpmyadmin die Datenbank direkt ergänzen, indem einfach per "Importieren" dieses SQL-Skript ausgeführt wird.
Diese Einzelfrage kann deshalb als erledigt angesehen werden. Es ist ziemlich einfach, es so durchzuführen und in die Beschreibung aufzunehmen. -- Jürgen 10:58, 27. Dez. 2011 (CET)

[Bearbeiten] WB-Einstellungen zu MW oder CSS

In der Vergangenheit wurden verschiedene Einstellungen in Wikibooks vorgenommen, beispielsweise der Typ collapsible. Welche derartigen Einstellungen sollten in einem lokalen Wiki vorgesehen werden? Genügt es, entsprechende Seiten (welche) per Export und Import zu übertragen, oder sind andere Schritte (welche) notwendig? -- Jürgen 10:06, 20. Dez. 2011 (CET)

Ich habe jetzt die folgenden Einstellungen per Spezial:Export geholt und per Spezial:Import übernommen:
Selbstverständlich habe ich den Browser-Cache anschließend geleert. Die gewünschten Anpassungen gelingen mir aber noch nicht:
  • Die Vorlage:Klappbox, die auf collapsible basiert, bringt die Anzeige vollständig durcheinander (das linke Bild: die eingekreisten Teile gehören in den Randbereich, die Klappbox "Liste der Erweiterungen" steht nur als Rahmen da ohne Markierung und nicht-verborgen). Könnte es sein, dass mw.loader.load('http://en.wikibooks.org... mit dem Standard-MediaWiki noch nicht funktioniert, sondern eine weitere Maßnahme erforderlich ist?
  • Die "Helferlein" werden bei den Einstellungen nicht angezeigt, obwohl Extension:Gadgets installiert ist (inkl. require_once in den LocalSettings). Müssen auch die System-Nachrichten übertragen werden? Fehlt eine weitere Extension oder Einstellung?
  • Seit dem Import der CSS-/JS-Seiten muss relativ oft eine Seite doppelt aufgerufen werden, bis die Anzeige stimmt (siehe das rechte Bild - der WMF-Stil wird erst beim zweiten Aufruf gültig). Dieser Fehler passiert "online" üblicherweise häufig dann, wenn die WMF-Server überlastet sind. Gibt es eine geeignete Maßnahme, um die sofortige Anzeige zu klären?
MW lokal Probleme 1.jpg MW lokal Probleme 2.jpg
Eigentlich wollte ich nur eine einfache lokale Installation von MediaWiki erreichen und beschreiben. Aber für ein gutes angepasstes lokales Arbeiten ist doch mehr nötig. Auch wenn ich mich inzwischen erheblich intensiver mit der Software beschäftige als geplant, fehlt mir für manche Sachen das Verständnis und die Kenntnis. Es wäre nett, wenn mir jemand helfen könnte. -- Danke und die besten Wünsche für das neue Jahr! Jürgen 16:20, 1. Jan. 2012 (CET)
Grrh. Man darf es sich nicht zu einfach machen und manche Stellen übergehen. Als ich jetzt die Beschreibung der MW-Konfiguration aktualisieren wollte (sie bezieht sich noch auf das alte Formular bis 1.16), habe ich festgestellt, dass meine lokale Installation ungenau oder unzureichend vorgenommen wurde:
  • Ich hatte mich auf den MediaWiki-Hinweis verlassen: "Die verbliebenen Konfigurationseinstellungen können übersprungen und das Wiki umgehend installiert werden."
  • Tatsächlich stehen auf der "übersprungenen" Konfig-Seite einige nützliche Möglichkeiten, z.B. die Aktivierung der Gadgets.
Also muss ich diese Einstellungen ausprobieren, bis ich wieder jammern darf, weil ich nicht weiterkomme. -- Jürgen 18:21, 15. Jan. 2012 (CET)

[Bearbeiten] Bild hochladen

Ich komme mit der Anleitung zum Bilder hochladen nicht klar. Angeblich soll es links unter Werkzeuge eine Möglichkeit geben, die ich aber nicht finde. Ich bräuchte einen Tip. -- Axhuelsmann 00:02, 18. Jan. 2012 (Signatur nachgetragen von: Jürgen 08:54, 18. Jan. 2012 (CET) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)

der dritte link von oben: "Datei hochladen". -- ThePacker 00:03, 18. Jan. 2012 (CET)
Dieser Link ist erst sieben Tage nach der Anmeldung freigeschaltet. Für Bilder zu Software gibt es weitere Bedingungen zum Urheberrecht; sehr oft ist das Hochladen auf Commons vorzuziehen. -- Jürgen 08:54, 18. Jan. 2012 (CET)

[Bearbeiten] Schwesterlinks funktionieren nicht mehr richtig

Betr. Kategorie:Vorlage für Sisterlinks
Wikibooks
Die englischen Wikibooks hat das Lehrbuch:

Wie ihr seht funktioniert das Verlinken auf die englischsprachige Wikibooks nicht mehr so, wie ich es gewohnt bin. Gibt es da einen Grund, oder hat sich der Syntax geändert? Gruß --mjchael 17:32, 5. Feb. 2012 (CET)

Wenn es in der Vergangenheit so funktioniert hatte, dann hat sich vermutlich wirklich etwas geändert, und zwar mit MediaWiki-Version 1.18.1. Ich hatte auch schon so einen Verdacht, habe es aber nicht genauer untersucht. Da ich mich für Ein lokales Wiki mit MW etwas befassen musste, vermute ich, dass ein paar Einträge der Tabelle der Interwiki-Links geändert wurden. Folgende Verweise funktionieren:
Wikibooks
Und im englischen Wikibooks:
Da wir uns auch im Bereich "b" befinden, wurde vermutlich ein Interwiki-Datensatz für "b" vergessen. Die Vorlage:WikibooksEn enthielt wohl von vornherein einen kleinen Fehler (es fehlt der Doppelpunkt vor dem Buchnamen). Weil ich diese Vorlage nicht gesehen hatte, hatte ich Vorlage:EN-WB-Hinweis erstellt, und die klappt. Wie man das Problem jetzt am besten angeht, das weiß ich freilich nicht. -- Jürgen 18:48, 5. Feb. 2012 (CET)

[Bearbeiten] Hauptautor inaktiv

Hallo,

ich arbeite seit Kurzem an einem Wikibook das es zwar schon lange gibt, dass aber nie so richtig verrann gekommen ist. Der Hauptautor scheint das Projekt nur angeschoben zu haben und hat, so wie ich das den Versionsgeschichten entnommen habe, schon seit 2008 nichts mehr an dem Buch getan. Ich habe das Buch in einem Forum zum dem Thema vorgestellt und ein paar Co-Autoren gewonnen. In den letzten zwei Wochen haben wir es auch gut voran gebracht. Ich frage mich jetzt aber in wie Weit es Sinn macht, wenn jemand Hauptautor ist, der seit fast fünf Jahren nichts mehr an dem Buch getan hat. Und ob es möglich ist einen anderen Hauptautoren zu benennen. Ich habe dem Nutzer schon letzte Woche eine Nachricht auf der Diskusionsseie hinterlassen und heute eine E-Mail geschrieben. Was kann ich tun, wenn er sich nicht meldet? Ich will ja nicht einfach einen anderen Hauptautoren benennen (mich selber auch nicht unbedingt, wenn sich jemand anderes bzw. qualifizierteres findet). Wenn sich sonnst niemand findet würde ich aber ggf selber die Patenschaft übernehmen.
MfG J C D 19:50, 10. Feb. 2012 (CET)

Unter den gegebenen Umständen ist das völlig unproblematisch. Wer auch immer von eurer Gruppe sich verantwortlich fühlt, kann und sollte sich eintragen. Weil die Initiative von dir ausging, kommst in erster Linie du dafür infrage; aber in der Entscheidung seid ihr frei. -- Jürgen 20:42, 10. Feb. 2012 (CET)
Ich habe das Wachstum des Buches Haltung von Süßwassergarnelen gesehen, und finde dass das Buch dadurch sehr gewonnen hat. Wikibooks sind auf Zusammenarbeit angelegt. Dem Hauptautor wird zwar etwas mehr Rechte eingeräumt, was die Gestaltung des Buches angeht (einfach da davon auszugehen ist, dass er am meisten zum Buch beitragen wird), aber es ist nicht unüblich, dass die Co-Autoren sehr stark an der Gestaltung beteiligt sind. Solange vom Hauptautor kein Einspruch kommt, und solange man mit dem vorhandenen Text nicht respektlos umgeht, wird sich keiner gegen eine Mitarbeit sperren. Es ist nicht viel anders wie bei den Wikipedia-Artikeln. Oftmals kommt es vor, dass mehrere Autoren die Patenschaft eines Buches übernehmen, und es somit mehrere Ansprechpartner gibt. Wer letztlich federführend ist, wird die Zeit zeigen. Schön, dass sich neue Autoren dem Buch annehmen. Gruß --mjchael 11:27, 11. Feb. 2012 (CET)
Ich habe es inzwischen geschafft den Hauptautor zu kontaktieren. Er hatte halt keine Zeit mehr und war wohl auch etwas frustriert weil er damals keine aktiven Mitautoren gefunden hatte. Er ist bereit die Rolle des Hauptautors abzugeben, wobei mir die Herangehensweise mit mehreren Paten sympathischer ist. Denn auch wenn ich mich kurzfristig dem Projekt angenommen habe, weiß ich nämlich selber nicht, wie das bei mir mit Zeit bzw. Motivation in der Zukunft aussieht. Weswegen ich mich jetzt auch nicht darum reise, dauerhaft die Rolle des Hauptautors einzunehmen. MfG -- J C D 12:16, 11. Feb. 2012 (CET)
Die Herangehensweise finde ich ziemlich gut, und genau so wurde es letztendlich bei meinem Buchprojekt Gitarre gemacht. Ich wurde ein zweiter Pate des Buches. Erst als der Initiator rein faktisch sich über Monate und Jahre nicht mehr am Projekt beteiligt hatte (wohl, weil es doch ein Megaprojekt ist, und man sich doch viel Zeit dafür nehmen muss) habe ich die Federführung an mich genommen. Sollte sich aber irgendjemand bereiterklären mitzumachen, dann werde ich mich nie gegen einen weiteren Autoren sträuben. Ich würde dir raten, zuerst mal dich als weiterer Ansprechpartner aufstellen zu lassen. Denn ich halte es nicht für unwahrscheinlich, dass sich der Initiator doch wieder ermuntert fühlt, noch etwas dazu beizutragen, wo er doch sieht, dass es inzwischen weitere Co-Autoren gibt. Es macht hier rein gar nichts, wenn man sich die Lorbeeren teilt. Es ist ganz sinnvoll, wenn du auch die Diskussions-Seite des Buchinitiators mit beobachtest, damit du evtl. Diskussionen mitbekommst, die das Buch betreffen, und um die du dich letztlich kümmerst. Ich wünsche euch, und besonders dir viel Erfolg mit eurem Buchprojekt. Wenn es Probleme mit Formatierung, Navigation, Formatforlagen etc. gibt, darfst du mich ruhig direkt ansprechen. --mjchael 17:48, 12. Feb. 2012 (CET)

[Bearbeiten] Wikibooks für E-Reader

Guten Tag,

ist es geplant, dass man mittelfristig Wikibooks als epub oder mobi herunterladen kann?

--Junior zanett1 02:29, 15. Feb. 2012 (CET)

Was meinst du mit "mobi"? Mobiltelefon, mobiler Computer (= Notebook) oder was sonst?
Deine Frage kann dir hier vermutlich niemand beantworten. Grundlage ist die MediaWiki-Software, die aus gespeicherten Seiten (mit Wiki-Syntax) etwas machen muss, was auf dem Zielgerät angezeigt werden kann. Standard ist HTML für Browser; Zusatz ist PDF. Hinzu kommt, dass es (noch) keinen Standard für E-Book-Reader gibt, diese Verfahren Nachteile haben und ihre Zukunft noch nicht gesichert ist. Als Fazit kann deshalb nur gelten:
  • Es gibt als Erweiterung zur MediaWiki-Software die Extension EPubExport. Frage dort, welche Erfahrungen es damit gibt. (en.Wikipedia und en.Wikibooks haben es nicht installiert.)
  • Suche, ob ein Wiki diese Extension benutzt; auf mwusers habe ich nichts dazu gefunden. Oder installiere dir ein lokales Wiki und probiere es selbst aus.
  • Wenn du feststellst, dass diese Erweiterung nützlich ist, dann mache einen Verbesserungsvorschlag. Vorschläge für Erweiterungen werden erfahrungsgemäß nur sehr selten übernommen.
  • Am einfachsten ist aber: Benutze einen E-Book-Reader, der PDF laden und darstellen kann, und hole dir die PDF-Version eines Buches.
Mir ist die Konvertierung nach ePUB auch schon durch den Kopf gegangen. Ich glaube aber, noch ist die Zeit dafür nicht reif. -- Jürgen 09:06, 15. Feb. 2012 (CET)

Es gibt durchaus Menschen die das HTML was du hier siehst mit Calibre nach epub konvertieren. Das tut es erst einmal. Epub ist technisch HTML sehr ähnlich. Ich habe selbst auch schon über derartige Möglichkeiten nachgedacht. Ich habe ein Programm was LaTeX erzeugt. Aus Latex kann man mit tex4ht oder pandoc html gewinnen. Aber ich finde es im Moment nicht interessant genug diesen Weg zu Ende zu gehen. Dirk Huenniger 09:58, 15. Feb. 2012 (CET)

Wie geht das? Müsste man dann jede Seite des Wikibooks einzeln kovertieren oder kann man das Buch auch "in einem Rutsch" konvertieren?--Junior zanett1 13:40, 15. Feb. 2012 (CET)
Anläßlich der Nachfrage eines Verlages habe ich mir gerade letztens ePub mal angesehen, das ist ein Standardformat, anders als mobi (wo man auch von den 'Erfindern' nicht viel drüber findet). Der Inhalt ist einfach XHTML, CSS, SVG, PNG, JPEG und ein wenig DAISY (auch ein XML-Format) und einfache Textdateien und eine XML-Datei zur Konfiguration.
Alles in allem ist es sehr einfach, das alles (mal abgesehen von der optionalen Pixelgraphik natürlich) mit einem Texteditor zu erstellen und daraus dann ein ZIP-Archiv zu machen und fertig ist das ePub-Buch ;o) Wie man sich denken kann, ist die Qualität gut, weil XML/XHTML als Grundlage dient und das läßt sich gut auf Monitoren lesen - vor allem deutlich besser als PDF, was sich wie postscript besser zum Drucken als zum Lesen auf eibnem Monitor mit dem Autor unbekannter Größe eignet. Da die Wikibooks ja auch in XHTML realisiert sind, eignet sich ePub viel besser als PDF, um daraus ein elektronisches Buch zum Mitnehmen zu machen.
Ich habe auch mal ausprobiert, was passiert, wenn man das Buch mit Calibre in andere Formate konvertiert - und was dabei herauskommt, ist minderwertiger Blödsinn. Bei PDF bleiben nichtmal die Metainformationen erhalten, das Darstellungsprogramm kann nicht mal mehr identifizieren, wer der Autor des Buches ist - eine Konversion von ePub zu PDF ist also auf jeden Fall unsinnig. Bei anderen Formaten wie mobi, fiction-book wird die semantische Auszeichnung geschreddert. Ich vermute mal, fiction-book kann eindeutig mehr als Calibre da fabriziert, bei mobi bin ich mir nicht sicher. Von einer automatischen Konversion mit irgendwelchen Programmen in andere Formate als ePub ist jedenfalls dringend abzuraten, da gibt es jedes Mal deutlichen Informationsschwund.
Doktorchen 10:37, 15. Feb. 2012 (CET)
mobi ist das Kindle-eigene Format (ePub wird aus kommerziellen Gründen nicht unterstützt). Ich hab allerdings gelesen, dass man mit Calibre ePub sehr leicht nach mobi konvertieren könnnte.
Auf meinem E-Book-Reader (Kindle 4) ist das lesen von PDFs sehr umständlich, die Schrift ist in der Regel sehr klein und man muss den Kindle auf "quer" stellen, damit man überhaupt was lesen kann.
Wenn man mit Calibre ein PDF in mobi konvertiert, dann werden die Bilder am Anfang gesammelt und es gibt sonst noch unsinnge Zeilenumbrüche. Der "richtige Weg" wäre dann, wenn ich es richtig verstanden habe, das HTML "im Browser" in ein
ePub zu konvertieren (für sonstige E-Book-Reader) und für die Kindle-Benutzer von ePub nochmal in mobi. Korrigiert mich bitte, wenn ich falsch liege. --Junior zanett1 13:40, 15. Feb. 2012 (CET)

Das HTML wäre (bei ePub 2) nach XHTML 1.1 zu konvertieren, mit UTF-8-Kodierung. Dies kann man dann wie bereits kurz angedeutet zusammen mit einigen zusätzlichen Konfigurationsdateien und dem Inhaltsverzeichnis in ein ZIP-Archiv verwandeln und hat dann ein Buch im Format ePub. Typische browser konvertieren HTML weder nach XHTML noch nach ePub. Da HTML oft fehlerhafte Markierungssuppe ist, wäre solch eine Konversion automatisch auch gar nicht so einfach. Die browser basteln sich zwar selbst aus der Suppe ein konsistentes DOM, ob man das aber irgendwo als XHTML ausgeben lassen kann, ist mir nicht bekannt. Die gängigen browser haben ja einen hochgezüchteten Markierungssuppen-parser für fehlerhaftes HTML eingebaut. Lesegeräte für ePub müssen sowas nicht haben, da dort XHTML und XML vorgegeben ist, da reicht ein einfacher XML-parser, da solche Dokumente per Definition nicht fehlerhaft sein können, handelt sich sonst nicht um XML/XHTML. Nach meinem Eindruck sollte man PDF nicht verwenden, da ist der Qualitätsverlust zu groß und man muß bei der Erzeugung möglichst exakt die Größe des Anzeigebereiches, die Sehfähigkeit/schwäche des Lesers und die bevorzugte Schriftgröße kennen, sonst läßt sich sowas schlecht lesen, besonders bei diesen oft kleineren elektronischen Büchern. mobi - also jedenfalls das, was Calibre da aus meinem ePub erzeugt hat, war qualitativ nicht besonders brauchbar. Auch weil ich da keine weiteren Informationen über das Format gefunden habe und das wohl auch firmenspezifisch ist, würde ich von dem komplett abraten und auch von Geräten, die statt ePub oder fiction-book nur dieses Format anzeigen können - das ist alberne Abzockerei durch den Versuch, die Leute mit dem Gerät ans eigene Format zu binden, obwohl es ein gutes Standardformat gibt. Wenn man nur den Anspruch hat, irgendwelchen Buchstabensalat umzurühren, funktionieren solche Formatkonversionen natürlich als Mixer und Rührstabersatz ganz passabel. Wenn in dem Text relevanter Inhalt steht, sollte man schon bei XML/XHTML/ePub bleiben und ein wenig mehr Arbeit investieren. Das Problem bei den wikibooks hier ist natürlich, daß nur die Ausgabe XHTML1.0 transitional ist, nicht was man da editieren kann. Die Ausgabe indes enthält natürlich auch noch viel, was man für solch ein ePub-Buch nicht wirklich brauchen kann. Da sollte man dann schon ein wenig Arbeit einkalkulieren, die Navigation wird man ohnehin neu zusammenbasteln dürfen. Das ePub kann allerdings aus beliebig vielen einzelnen XHTML-Dokumenten bestehen, man muß also nicht die XHTML-Dokumente selbst alle zu einem vereinen.

Um mal ein Beispiel zu geben - um manuell aus zehn XHTML1.0 transitional Seiten mit ISO-Kodierung ein passables ePub-Buch zu machen, habe ich bereits beim ersten Versuch (nur) einen Nachmittag gebraucht - inklusive Rechtschreibkorrektur bei der Gelegenheit. Allerdings kenne ich mich mit XHTML und XML inzwischen auch ganz gut aus ;o) Beginnt man mit HTML, muß man da schon mit etwas mehr Zeit rechnen, hängt aber stark davon ab, wie mangelhaft das ist und wie stark die Notation von XHTML abweicht, man kann HTML durchaus so notieren, daß eine Konversion nach XHTML nur sehr wenig Zeit kostet, tun aber leider nur wenige.

Ein weiteres Problem ergibt sich mit dem Rauf- und Runterladen, weil aktuell ePub, mobi, fiction-book etc gar nicht als hier erlaubte Formate vorgesehen sind. Wenn man es also erzeugt, müßte man es wohl trotzdem auf einem anderen server bereitstellen oder die Administration überzeugen, ePub hier zu erlauben, wobei allerdings auch die Diskussion über CSS und ZIP bereits im Sande verlaufen zu sein scheint ;o) Doktorchen 14:29, 15. Feb. 2012 (CET)

Also im Prinzip würde ich zum Kauf eines Gerätes Raten das PDF darstellen kann. Es gibt schöne Tablet PCs, die haben auch hinreichende Bildschrimfläche, können Farben darstellen und sind bezahlbar, teilweise schon ab etwa 100EUR. Ansonsten gibt es für die meisten Wikibooks eine Druckversion, die ist HTML (welches mit ziemlicher sicherheit nicht wohlgeformt ist), dies kann man in Calibre reinstopfen und epub rausholen. Ob das (x)html welches in dem epub steht wohlgeformtes XML ist weis ich nicht. Wenn man glück hat kann man es jedenfalls auf dem Reader lesen. Das sollte man ausprobieren da das nur sehr wenig zeit braucht. Ansonsten nehme man wb2pdf. Das produziert ein Latex File. Das ist ein korrekt geklammerter Baum und damit bis auf Umbennung ein wohlgeformtes XHTML Dokument. Diese Umbennenung kann man von Pandoc ausführen lassen. Das geht auch erfahrungsgemäss ganz gut und man hat dann xhtml. Aus der Tagsoup bei Wikibooks ein wohlgeformtes XHTML zu gewinnen ist damit durchaus machbar. Dirk Huenniger 14:57, 15. Feb. 2012 (CET)

Also die Ausgabe hier ist schon, wie ich bereits sagte, als XHTML 1.0 transitional in den Dokumenten notiert, mit UTF-8-Kodierung, kein HTML, es wird lediglich fälschlich als text/html ausgeliefert. Strukturfehler gibt es da vom wiki her nicht, mag aber sein, daß dies keine Fehler korrigiert, die Autoren mit dem Editor als (X)HTML-Quelltext reinbasteln. Von daher dürfte die einfachste Methode sein, aus dem Quelltext der Ausgabe die entsprechenden Fragmente in ein Grundgerüst für XHTML 1.1 zu kopieren und die verbleibenden Fehler mit einem Validator zu finden und dann zu korrigieren, das dürfte überschaubar sein, anders als bei beliebigem HTML, welches von Autoren irgendwie außerhalb von wikibooks erzeugt wird.
Mit Calibre von HTML-Markierungssuppe nach ePub konvertieren, habe ich eben ausprobiert, also etwas, was zumindest XHTML 1.0 transitional ist, kommt dabei wohl heraus, mal abgesehen von kleineren Inkonsistenzen (Metaangabe hinsichtlich der Kodierung nicht von ISO auf UTF-8 geändert, die Kodierung selbst schon, da aber andererseits UTF-8 korrekt in der Verarbeitungsanweisung steht, allenfalls ein Problem für fehlerhafte Programme). Von daher als erster automatischer Schritt schon mal nicht schlecht. Die Semantik nimmt dabei auch keinen Schaden, auch das ist schon gar nicht schlecht für Calibre, der das bei anderen Konversionen offenbar gerne zersägt. Allerdings bläht Calibre den Quelltext gerne mit überflüssigen class-Attribute auf, was sicher suboptimal für die manuelle Nacharbeit ist.
Da die wenigsten Lesegeräte natürlich prüfen werden, welche Version von XHTML verwendet wird, werden die schlimmstenfalls den veralteten Kram einfach ignorieren, was aber meist nur Auswirkungen auf die Dekoration hat, nicht den Inhalt. Wie man aus mehrere (X)HTML-Dokumenten mit Calibre ein Buch macht, habe ich allerdings kurzfristig nicht gesehen. Es ist natürlich sinnvoll, bei größeren Büchern für jedes Kapitel etwa ein (X)HTML-Dokument zu verwenden und nicht etwa Calibre den Kram zufällig einteilen zu lassen.
Der Nachteil von PDF gegenüber ePub, fiction-book etc ist eben das starre Layout, weswegen sich das generell nicht sonderlich fürs Lesen am Bildschirm eignet. Da hilft auch kein noch so toller Bildschirm. Egal bei welchem, ich bin da immer man hin- und herskalieren und schieben und drücken, um PDFs vieler Autoren halbwegs brauchbar am Bildschirm lesen zu können - die hier an der Uni mit LaTex selbst erstellten sind merkwürdiger Weise deutlich besser lesbar, mag also zumindest zum Teil auch an den Autoren/Programmen liegen ;o)
Solange man das Dokument nicht druckt, ist PDF daher immer eine Krücke, besser als nichts, aber weit weg von optimal geeignet.
Doktorchen 17:17, 15. Feb. 2012 (CET)

Es ist halt so das der geneigte Wikibooks-Autor gerne wie folgt formuliert

Dieser Text ist <b>''fettkursiv</b>''

Dieser Ausdruck ist offenbar falsch geklammert. Das erzeugte HTML ist daher nicht wohlgeformt. Wenn man ein solches Dokument parsen will bemerkt man leicht das dass zulassen deratiger Klammerung wegen dem Pumping Lemma dazu führt das die Sprache nicht kontextfrei ist. Woraus folgt, dass keine Backus Naur Form existiert und damit im Wesentlichen keine Parsing-Bibliothek, Dennoch schreiben viele das halt genauso hin, was zu grauen Haaren führen kann. Und selbstverständlich gibt es in der allseits sehr gebräuchlichen Programmiersprache Haskell eine Parsingbibliothek die auch nicht kontextfreie Grammatiken zulässt. Die ist auch sehr schön benutzen wenn man den einmal die fast völlig triviale Theorie der Monaden verstanden hat über die man sich in jedem Buch über Kategorientheorie leicht informieren kann. Dirk Huenniger 17:44, 15. Feb. 2012 (CET)

Solchen Schabernack müßte die wiki-software ja bereits auflösen, wenn die Anführungstriche in Elemente umgesetzt werden. Eine konsistente Regelung dafür könnte sich etwa aus dem HTML5-Entwurf ergeben, ich meine, da steht ein Vorschlag geschrieben, wie verwandte Markierunssuppe wie
Dieser Text ist <b><i>fettkursiv</b></i>
in eine brauchbare DOM-Konstruktion konvertiert wird (das basiert dann wie meistens bei HTML5 nicht auf irgendeiner Logik, sondern auf historischem Zufall, was auch damit zu tun hat, daß Leute, die HTML-parser für browser schreiben, nicht erst Theorien studieren, sondern einfach irgendwas zusammnenbasteln, was jetzt versucht wird, als HTML5 zu verkaufen) ...
Generell sollte natürlich irgendeine Regel in der wiki-software reichen, um das Problem gar nicht erst im XHTML-Quelltext erscheinen zu lassen - der Autor sieht das Problem dann im Zweifelsfalle ja in der Vorschau ;o)
Zwangsläufig bleibt natürlich das Aufräumen an der wiki-software hängen, die XHTML erzeugt, denn wenn das schon eine eigene Syntax verwendet, um gewissen Leuten das Schreiben zu erleichtern (tut es das wirklich? sieht für mich oft viel kryptischer und komplizierter aus als XHTML), sollte die Konversion nach XHTML dann auch gut durchdacht sein, nicht in dem Sinne, daß aus Schabernack was Sinnvolles wird, sondern wenigstens eine formal korrekte Struktur.
Doktorchen 18:13, 15. Feb. 2012 (CET)

Hab gerade mal geschaut, die Wikisoftware korrigiert in der Tat solche Schabernack völlig korrekt. Dann sollten wir sogar bereits ein XHTML Dokument aus dem Wiki bekommen und dann mit Calibre alles gut nach epub kriegen.

Was das Problem mit der Lesbarkeit von PDFs angeht. Ich denke das liegt daran das viele Autoren Bitmapfonts verwenden.Dirk Huenniger 18:35, 15. Feb. 2012 (CET)


Bei sowas ahnt man ja noch, was der Autor gemeint haben könnte, und unterschiedliche Interpretationen fallen da oft noch gar nicht auf. Viel lustiger sind da noch solche Sachen:
<p>Dieser Text <b>ist <i>fettkursiv</b>, oder?</i> oder doch?</p>
Wenn man da jetzt 3 bis 4 unvoreingenommene Programmierer dransetzt, bekommt man sicher auch gleich 3 bis 5 verschiedene Ergebnisse ;o) Heuristisch würde ich da die Endmarkierung für b einfach ignorieren und dies dann erst mit Abschluß des p-Elternelementes schließen lassen, ohne darüber zu reflektieren, was der Autor mit dem Blödsinn gewollt haben mag ;o)
Das Problem mit den PDFs hängt auch oft damit zusammen, daß das Verhältnis von Schriftgröße zu Dokumentenbreite schlecht gewählt ist. Je nachdem, womit, mit welch hochauflösendem Monitor man sich das anguckt und wie gut oder schlecht man gucken kann, hat man dann die Wahl, in den Monitor reinzukriechen oder horizontal zu rollen - oder einfach was anderes zu lesen. LaTex haut hingegen meist automatisch eine brauchbare Schriftgröße raus oder wissenschaftliche Artikel erscheinen zweispaltig, da fällt das Drama nicht so auf - obwohl ich letztere auch meist lieber ausdrucke, bevor ich sie komplett lese.
Doktorchen 18:54, 15. Feb. 2012 (CET)

Also ich denke das soll folgendes heißen

<p>Dieser Text <b>ist <i>fettkursiv</i></b><i>, oder?</i> oder doch?</p>

Der Stack ist pbi. Es geht b zu. Damit b zugehenkann muss erst einmal alles rechts von b auf dem Stack zu. Dann muss b zu. Dann muss alles was rechts vom b stand wieder auf. In diesem Falle also nur i. Der Stack ist nun bi. Dann geht geht i zu. Der Stack ist nun b. Dann geht b zu und der Stack ist leer. So treibe ich das jedenfalls.Dirk Huenniger 19:10, 15. Feb. 2012 (CET)

Das ist tückisch, denn das erzeugt ja ein ganz neues, zweites i-Element aus dem Nichts. Hätte der Autor zwei i-Elemente gewollt, hätte er sie hingeschrieben ;o) Sporadisch vorhandene automatisch erzeugte/implizierte Elemente gibt es leider in HTML und sind besonders gefürchtet bei der Dekoration mit CSS, denn das bringt die Kaskade durcheinander. Bei XHTML wird hingegen nichts impliziert - ein besonders schöner Fall für die Konversion von HTML nach XHTML ;o)
Oben beschriebenes Vorgehen richtet sich eher nach der Verschachtelung, da im i kein b auf ist, kann man auch keines schließen, also ist die Endmarkierung falsch und kann gestrichen werden. Da aber i und b inzeilige Elemente sind, sind sie spätenstens zu schließen, wenn das Blockelement drumherum schließt, also ist auch
<p>Dieser Text <b>ist <i>fettkursiv, oder?</i> oder doch?</b></p>
eine plausible Lösung. Das ist für HTML-Markierungssuppe besonders naheliegend, weil da bei einigen Elementen Endmarkierungen ohnehin optional sind und man die Bedeutung der Elemente kennen muß, um sie automatisch schließen zu können. Z.B. ist in HTML die Endmarkierung vom p optional, die wird automatisch gesetzt, wenn das nächste Blockelement auftaucht.
Ein weiterer Ansatz wäre, alle Kindelemente immer automatisch zu schließen, wenn das Elternelement geschlossen wird, dann muß man nichts über die Semantik der Elemente wissen und hat eine allgemeine Regel. Zudem streicht man überflüssige End-Markierungen:
<p>Dieser Text <b>ist <i>fettkursiv</i></b>, oder? oder doch?</p>
Eine weitere ist die obligatorische XML-Variante: Fehlermeldung hinschreiben statt zu raten. Etwas freundlicher wäre es dann noch, alle Markierungen zu streichen, die fehlerhaft sind, also hier sowohl b als auch i.
Doktorchen 19:46, 15. Feb. 2012 (CET)

Ich bleibe jedenfalls bei meiner Software bei meiner Variante. Die weiteren beschriebenen sind jedoch auch sehr vergnüglich. Wenn jemand richtig klammert kommt das richtige Ergebnis raus und wenn jemand falsch klammert kommt hat irgendein Ergebnis raus und mein Algorithmus ist sehr kurz und knapp zu formulieren. Das Ergebnis erinnert zumindest entfernt an die Intension des Autors, sofern eine solche denn vorhanden war.Dirk Huenniger 20:17, 15. Feb. 2012 (CET)

Die Aufspaltung eines Elementes in zwei wird auch problematisch, wenn da sowas steht:
<p>Dieser Text <b id="b1">ist <i id="i1">fettkursiv</b>, oder?</i> oder doch?</p>
Wenn der Fragmentidentifizierer eine Funktion hat, zeigt ja wohlmöglich irgendwas anderes auf das Element, auf was soll das zeigen, wenn man ein Element in zwei aufteilt? Ähnlich problematisch wären da natürlich Korrekturversuche, wo man Elemente ganz streicht, denn dann könnte irgendwas ins Leere zeigen ...
Selbst ohne die Fragmentidentifizierer könnten CSS-Selektoren so geschickt formuliert sein, daß man bei einer Aufteilung in zwei Elemente nur eines davon erwischt - und plötzlich ist kursiv nicht mehr so kursiv dekoriert, wie der Autor es gerne gehabt hätte. Bleibt letztlich dabei, daß bei einem komplizierteren Dokument die Konsequenzen des Fehlers oder der Korrektur kaum allgemein überschaubar sind und so eine optimale automatische Korrektur ein Problem bleibt.
Doktorchen 10:17, 16. Feb. 2012 (CET)

[Bearbeiten] SIP-Telefonie

Hallo, ich habe bereits ein PDF-Buch erstellt, das aber auf meiner privaten Website natürlich keinen großen Leserkreis findet. Ich würde es hier gerne einem breiteren Leserpublikum zur Verfügung stellen. Das Thema ist ein Leitfaden vom Gedanken bis zur Umsetzung von SIP-Telefonie. Im Umfang etwa mit dem hier vegleichbar, allerdings befasst sich meins ausschließlich mit SIP (statt Protokolle zu vergleichen) und ist mehr ein Leitfaden zur Umsetzung, statt Hintergründe und Pro-/Kontra-Analysen zu berücksichtigen. Die Zielgruppe ist eingegrenzt: Privatpersonen und Selbständige, die bereits VoIP ihres ISPs verwenden, aber von SIP und der aktiven Nutzung von SIP-Adressen keine Ahnung haben. Mein Buch hat also von daher einen völlig anderen Ansatz.

Mit Wikipedia bin ich vertraut, hier habe ich noch gar nichts gemacht. Deshalb meine Fragen:

  • ist es sinnvoller mich im vorhandenen Wikibook einzubringen oder ist es erwünscht, das neue Buch unabhängig davon anzulegen?
  • gibt es hier sowas wie ein Mentorenprogramm? Ich hab erfolglos danach gesucht; Wenn nicht: würden erfahrene Nutzer für sowas zur Verfügung stehen und wo bzw. wie trete ich mit jemand in Kontakt, der mein erstes Buch begleichten würde?
  • ist es üblich bzw. sinnvoll, das Buch ggf. im BNR anzulegen und später in den allg. Namensraum zu verschieben?

Bei den Überlegungen ist zu berücksichtigen, dass ich den Umfang des Buchs künftig noch erheblich ausweiten will und eigentlich beabsichtige, dem Umfang nach eine ausführliche und eine Kurzfassung anzubieten. Ich weiß allerdings nicht ob das so erwünscht ist.

Ich hoffe auf vollständige Antworten. --H7 11:01, 19. Feb. 2012 (CET)

Ich fange mit einer unvollständigen Antwort an.
  • Ein Buch, das sich mit SIP-Telefon befasst, sollte rein thematisch zu Wikibooks passen. Wie groß der potenzielle Leserkreis ist, hängt natürlich von der (künftigen) Verbreitung von SIP ab.
  • Ob du es als eigenständiges Buch erstellen willst, hängt von deiner Zielsetzung ab. Nach der Struktur von Wikibooks ist beides möglich -- sowohl die Einbindung in IP-Telefonie als auch ein eigenes Buch. Nach deiner Vorstellung als Leitfaden ist ein separates Buch wahrscheinlich sinnvoller.
  • Ein Mentorenprogramm o.ä. gibt es nicht. Es gibt das Wikibooks-Lehrbuch. Ein paar einleitende Hinweise werde ich auf deine Benutzerdiskussion setzen. Kontakte mit anderen Nutzern zur Hilfe gehen (wie immer) direkt über deren Diskussionsseiten oder hier über "Ich brauche Hilfe". Theoretisch passen die Diskussionsseite eines Buches oder Kapitels, aber da musst du damit rechnen, dass dir niemand antwortet. Nach einiger Zeit wirst du auch feststellen, wer für welche Fragen geeignet ist. (Im Laufe des letzten halben Jahres gibt es freilich immer weniger Nutzer, die sich für mehr als ihr eigenes Buch interessieren.)
  • Ob das Buch im Benutzer- oder im allgemeinen Namensraum begonnen wird, ist Geschmackssache. Ein Anfang im BNR ist (noch) relativ unüblich, wäre aber oft besser als ein Schnellschuss, der nach wenigen Tagen versandet. Da du ein fertiges Werk als Grundlage hast, sollte es sinnvoller sein, sofort das Buch mit seinen Kapiteln einzustellen.
  • Zwei Versionen sind durchaus nützlich. Sofern die einzelnen Kapitel einheitlich sind, wird das am besten durch zwei Druckversionen geregelt: [[Mein Buch/ Druckversion]] und [[Mein Buch/ Kurzversion]]. Die erste enthält dann alle Kapitel, die zweite nur die wichtigsten.
Vielleicht hilft dir auch diese unvollständige Antwort weiter. -- Jürgen 12:32, 19. Feb. 2012 (CET)
Vielen Dank! Ich denke ich werde mal mit einem Entwurf im BNR anfangen und Dich danach noch mal ansprechen. Dauert vielleicht 2-3 Tage; ich möchte es auch nicht 1:1 nur kopieren, sondern evtl. Vorwort und Inhaltsverzeichnis noch überarbeiten bzw. an der Gliederung feilen. Danach wird man sehen wie es weitergeht. Bis dahin erst mal vielen Dank für die Antwort, die ja schon recht vollständig war. (Ich habe befürchtet es kommen so 2-3 Sätze mit einem allg. Link, das allein hätte mir dann wenig genutzt.) --H7 14:27, 19. Feb. 2012 (CET)

[Bearbeiten] Buch übernehmen (Genetik)

Liebe Community,

ich würde gerne das Buch Genetik im Regal Biologie übernehmen und ein bisschen anders gestalten bzw. endlich beginnen zu schreiben. Habt ihr ein paar Tipps, wie man ein Buch am besten gestalten kann oder kann mir jemand dabei helfen, dieses Buch zu schreiben?

--Logicpro 15:34, 27. Apr. 2012 (CEST)

Hallo. Da das „Buch“ Genetik nur aus einer Absichtserklärung von Benutzer:Enigma besteht, der auch seit November nichts mehr gemacht hat, können wir den Anfang einfach löschen und du kannst loslegen. Tipps:
  • Genetik ist ein weites Feld. Überleg dir, worüber du genau schreiben willst und wie deine Gliederung aussehen soll
  • bei einzelnen Fragen helfen wir dir gerne weiter, mit Mit-Autoren kannst du erfahrungsgemäß aber nicht rechnen
  • am besten wäre also ein kleineres Teilgebiet, dass du alleine bewältigen kannst
--NeuerNutzer2009 16:04, 27. Apr. 2012 (CEST)
Hallo NeuerNutzer2009. Ich würde schon sehr gerne darüber schreiben. Auch wenn ich mir bewusst bin, dass dies ein sehr großes Themengebiet ist und ich sicherlich länger als ein paar Wochen oder Monate brauchen werde, bis das Buch vollendet ist. Wie schnell kommt man eigentlich zu eimem Feedback? Denn das, was ich schreibe, ist von Anfang an sicherlich nicht so verständlich, wie ich es gerne hätte. Was ich damit sagen will, es werden Anfangs sicher viele Fragen aufkommen. Bekommt man schnell Feedback auf den jeweiligen Diskussionsseiten? Schließlich will ich ja wissen, wobei es bei dem Buch hackt.
--Logicpro 16:20, 27. Apr. 2012 (CEST)
Genauso wenig wie mit weiteren Autoren kannst du auch kaum mit Rückmeldungen rechnen. Es ist viel zu sehr vom Zufall abhängig, ob Leser über das Buch stolpern und Kommentare dazu abgeben. Viel wahrscheinlicher ist es, dass ein Buch, das bereits ausreichend Inhalt hat, über Guckel weit nach oben rutscht und auf diesem Weg weitere Leser findet. Dann gibt es auch Kommentare. Wenn du "im Kopf" so etwas wie eine Konzeption hast, dann gehe nach den Hinweisen auf deiner Benutzerseite vor, wie ein neues Buch entstehen kann. -- Viel Erfolg! Jürgen 16:29, 27. Apr. 2012 (CEST)
Danke für eure Rückmeldungen. Werde mir mal alles durchlesen und das Buch dann beginnen, sobald ich mich dazu bereit fühle. --Logicpro 16:34, 27. Apr. 2012 (CEST)
Ich denke, am besten schreibst du erstmal eine grobe Inhaltsübersicht, Struktur mit beschreibenden Überschriften. Die kannst du doch problemlos als Vorschlag auf der schon bestehenden Seite unterbringen, die ja praktisch leer ist. Wenn du dich mit Genetik gut auskennst, wirst du doch auch sicher Leute (an der Uni?) kennen, die sich ebenfalls damit auskennen, die kannst du doch bitten, sich das mal anzusehen und ihre Meinung kundzutun. Auch kannst du dabei selber feststellen, wie umfangreich das Thema wird oder wie du die Struktur formulieren mußt, damit der Umfang überschaubar bleibt. Leute, die von Genetik nicht viel Ahnung haben, können dich inhaltlich sicher auch nicht beraten, die können allenfalls formale oder technische Sachen erkennen - etwa wenn der Inhalt nicht zur Überschrift paßt oder sonstige Zusammenhänge nicht allzu logisch erscheinen... Doktorchen 16:40, 27. Apr. 2012 (CEST)
Ich habe die Möglichkeit von einem 'inoffiziellen' Buch gelesen. Ist es auch einfach Möglich, ein Buch zu beginnen, ohne es in das Bücherregal einzutragen? Oder werden inoffizielle Bücher allgemein immer nur auf der Benutzerseite geschrieben? --Logicpro 17:38, 27. Apr. 2012 (CEST)
Nur auf Benutzerunterseiten. --NeuerNutzer2009 13:42, 16. Mai 2012 (CEST)

[Bearbeiten] Unerledigte Löschkandidaten

Bei uns können die Löschdiskussionen ja auch mal länger dauern. Ab und zu kann es dann auch passieren, dass ein Löschantrag „durchrutscht“. Bei einer Diskussion hatte Benutzer:Geitost vorgeschlagen, künftig „an einer bestimmten Stelle sichtbar vermerken, wo noch was aussteht, damit es nicht völlig vergessen wird“.

Meine Idee: Kann die Vorlage:LK-Intro so geändert werden, dass sie die Kategorie:Wikibooks:Offene Löschdiskussionen (o.ä.) verlinkt, solange der Parameter „|erledigt = “ nicht ausgefüllt ist? Damit hätte man eine Kategorie mit allen offenen LA-Seiten und dass einzige, was manuell gemacht werden müsste ist, nach dem Abarbeiten der Seite das erledigt-Feld auszufüllen (und das sollte bisher auch erfolgen). Meinungen? Wer kann Vorlagen programmieren? --NeuerNutzer2009 14:11, 16. Mai 2012 (CEST)

Ich habe in die Vorlage eine Kategorie:Wikibooks: Löschkandidaten eingefügt. Ebenfalls in die Vorlage:Löschantrag, so dass die Kategorie auch bei allen zukünftigen Anträgen per "subst" automatisch mit eingetragen wird. Die Vorlage Löschantrag enthält noch einen optionalen Parameter "nokat" der bei "nokat=true" verhindert, dass die Kategorie gesetzt wird. (Damit Hilfeseiten, wo die Vorlage nur vorgestellt wird, nicht auch als Löschkandidat erscheinen.). Ein anderer Admin, der sich besser mit unseren Vorlagen auskennt, sollte noch mal notwendige Kategorien ersetzen ((Kategorie:Wikibooks:Qualitätsmanagement|Löschkandidaten) wurde gesetzt) . Die Löschkandidaten erscheinen auch in der Todo-Liste der Admins. --mjchael 21:53, 17. Mai 2012 (CEST)

Sehr schön, Danke! --NeuerNutzer2009 23:15, 17. Mai 2012 (CEST)

[Bearbeiten] Hilfe! "Als PDF herunterladen" funktioniert nicht

Hallo, gestern ist mir auf en.wikibooks.org aufgefallen, dass "Download as PDF" nicht mehr funktioniert. Hier funktioniert "Als PDF herunterladen" auch nicht mehr. Aber auf Wikipedia funktioniert es. Seltsam. Kann irgendwer helfen oder die richtigen Leute anstossen? Danke! --Martin 09:57, 18. Mai 2012 (CEST)

A bugzilla report has been filed. --Martin 11:05, 18. Mai 2012 (CEST)
Es liegt offensichtlich an der MediaWiki-Version:
  • Wikibooks hat Version 1.20wmf3 (f4ebd67) per 17 May 2012 18:22:55.
  • Wikipedia hat Version 1.20wmf2 (29b4130) per 17 May 2012 18:20:48
Vielleicht ist WB wieder einmal Versuchskaninchen für irgendeine Verbesserung; und die Anpassungen wurden nicht richtig vorgenommen. Deshalb ist bugzilla der einzig sinnvolle Weg. Danke schön! -- Jürgen 15:51, 18. Mai 2012 (CEST)
Problem scheint (vorerst) gelöst zu sein. :) --Martin 23:40, 19. Mai 2012 (CEST)

[Bearbeiten] Traktorenlexikon: Iseki

hat eine IP aus dem Wikipedia-Artikel kopiert. Ist es möglich, alle Versionen der Seite von der IP zu löschen und nur die Änderung von Nammer95 zu behalten? Das ist nicht die einzige Herstellerseite mit Urheberrechtsverletzungen, aber die einfachste um anzufangen. --Trekkerfahrer 19:47, 20. Mai 2012 (CEST)

Von „http://de.wikibooks.org/w/index.php?title=Wikibooks:Ich_brauche_Hilfe&oldid=639127“
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Mitmachen
Werkzeuge
Drucken/exportieren