DE/Doku/Handbucherstellung

Konzept bzw. Vorgehensweise (Kurzfassung)
Die Erstellung deutschsprachiger Handbücher ist folgendermaßen geregelt:
 * Als Grundlage der deutschsprachigen Handbücher werden die englischen Handbücher herangezogen.
 * Im Wiki findet zunächst die Übersetzung bzw. eine Anpassung des Textinhaltes als ASCII-Text sowie ein Korrekturlesen statt (s. z.B. Allgemeine Einführung).
 * Im zweiten Schritt wird der ASCII-Text bei ODFAuthors in die endgültige Fassung gebracht, d.h. formatiert und mit Bildern versehen.
 * Anmeldung zu Mitarbeit an ODFAuthors: eMail an webmaster@odfauthors.org mit der Bitte um Zusendung von Zugangsdaten schicken.
 * Alle Punkte, die abgearbeitet worden sind und nicht mehr aktuell benötigt werden, sind auf die Seite DE/Doku/Handbucherstellung %28erledigte Punkte%29 verlagert worden, um diese Seite zu straffen.

Seit Anfang Juli 2013 gibt es eine alternative Vorgehensweise zum ersten Schritt, d.h. das Wiki wir nicht verwendet, sondern das "Etherpad" de_documentation.

Hinweis bzgl. Etherpad

The service is available at http://pad.documentfoundation.org In order to fight spam, pad creation has to be manually requested at the moment. Everyone can edit existing pads, but not create new ones. Be advised that all pads are listed on the index page, and are publicly accessible - editing of confidential information should happen elsewhere.

To request creation of a new pad, please write to hostmaster@documentfoundation.org

Data you put into the pad from now on will be preserved in our MySQL database, so it's now officially in production mode.

It is proposed to use the respective project's/mailing list names for the pads, like "qa", "marketing", "website", and prefix it with the language code where needed, like "de_marketing" or "it_qa".

Einstellen eines neuen Dokuments ins Wiki
''Mal so eine Frage in den Raum gestellt: Benutzt eigentlich einer von euch die Wiki-Publisher Extension, die von Sun erstellt wurde? Das dürfte (denke ich mir mal) doch verschiedene Sachen vereinfachen, oder? ''

Dokument vorbereiten:


 * Formate in Wiki-Format übertragen:
 * Alle Überschriften mit entsprechender Anzahl von "=" am Anfang und Ende ergänzen (Überschrift 1 mit "==", Überschrift 2 mit "===", usw.).
 * Aufzählungen: Jede Zeile mit "*" versehen.
 * Nummerierungen: Jede Zeile mit "#" versehen.
 * Definitionen: Jeden Term mit ";" und jede Definition mit ":" versehen.
 * Tabellen in Text umwandeln: Tabelle -> umwandeln -> Tabelle in Text... -> (als Trennzeichen: "Absatz"). (Gibt es eine Möglichkeit alle Tabellen auf einmal umzuwandeln?)
 * Hinweise, Tipps und Warnungen als Definitionen markieren (s.u.)
 * Abbildungen: Titel aus dem Rahmen ins Dokument kopieren, Bilder ggf. schon löschen
 * Gesamten Text markieren, Absatzvorlage auf "Standard" ändern (damit Nummerierungen und Aufzählungen richtig übernommen werden).
 * Suchen & Ersetzen: → ersetzen durch  ->

Dokument als Textdatei speichern und schließen (dabei gehen alle Bilder und Formatierungen verloren, was aber so gewollt ist).

Textdokument schließen, (in Writer) neu öffnen und weiter bearbeiten:

Textdokument ins Wiki kopieren
 * Leere Absätze löschen.
 * Absätze als Code formatieren:
 * Suchen & Ersetzen (Reguläre Ausdrücke aktivieren!!!): $ ersetzen durch  \n\n
 * Beim ersten Absatz noch  und beim letzten Absatz   ergänzen.
 * Aufzählungen, Nummerierungen und Definitionen richtig formatieren (Achtung, bei verschachtelten Nummerierungen sind alle Schritte u.U. mehrfach und abwechselnd durchzuführen!):
 * Suchen & Ersetzen:  ersetzen durch  *
 * Suchen & Ersetzen:  ersetzen durch  #
 * Suchen & Ersetzen:  ersetzen durch  ;
 * Suchen & Ersetzen:  ersetzen durch  :
 * Zusammenhängende Aufzählungen usw. zusammenbringen:
 * Suchen: ^\* und folgende Leerzeile manuell löschen. (Gibt es eine Möglichkeit, auch das zu automatisieren?)
 * Suchen: ^# und folgende Leerzeile manuell löschen. (s.o.)
 * Suchen: <tt style="background-color:#F09E6F; padding:1px 5px">^; und folgende Leerzeile manuell löschen. (s.o.)
 * Code aus Überschriften entfernen:
 * Suchen & Ersetzen: <tt style="background-color:#F09E6F; padding:1px 5px"> ersetzen durch <tt style="background-color:#92E285; padding:1px 5px">=
 * Suchen & Ersetzen: <tt style="background-color:#F09E6F; padding:1px 5px"> =  ersetzen durch <tt style="background-color:#92E285; padding:1px 5px">=
 * Tabellen einfügen:
 * Suchen und Ersetzen: <tt style="background-color:#F09E6F; padding:1px 5px">=$ ersetzen durch <tt style="background-color:#92E285; padding:1px 5px"> = \n\n{| width="100%"\n|-\n| bgcolor="#F2CBF8" width="25%" align="center" | Kü\n| bgcolor="#F9CFB5" width="25%" align="center" | (Name)\n| bgcolor="#FDE9A9" width="25%" align="center" | (Name)\n| bgcolor="#CCF4C6" width="25%" align="center" | (Name)\n|-\n| colspan="4" bgcolor="#F2CBF8" |\n
 * Suchen & Ersetzen: <tt style="background-color:#F09E6F; padding:1px 5px">^= ersetzen durch <tt style="background-color:#92E285; padding:1px 5px">|}\n\n=
 * Bei der ersten Überschrift nicht ersetzen oder wieder löschen.
 * Nach dem letzten Absatz noch manuell ergänzen.

Wie erkennt man Abschnitte, die noch nicht übersetzt worden sind?
Abschnitte, die noch nicht übersetzt worden sind, werden mit  "(Überschrift)"  versehen. Damit kann man erkennen, dass für diesen Abschnitt eine  Übersetzung ansteht.

Aufruf des Abschnittes, der übersetzt werden soll
Zur Übersetzung/Bearbeitung bitte den Absatz über den "Bearbeiten-Button"  rechts neben der Überschrift des jeweiligen Absatzes aufrufen (nicht die  für die ganze Seite), damit andere an anderen Absätzen parallel  arbeiten können).

Kenntlichmachung, dass ein Absatz gerade bearbeitet wird

 * Zur Kenntlichmachung, dass ein Absatz gerade bearbeitet wird, steht folgende Vorlage zur Verfügung:
 * Im Quelltext ist für jeden Abschnitt vorab eingetragen.  Kopiere aus diesem Text
 * Füge in die darunter  liegende Leerzeile ein und speichere zunächst die Wiki-Seite ab. Dadurch  wird diese Vorlage für alle sichtbar, d.h. es wird klar und deutlich  angezeigt, dass der betreffende Abschnitt gerade bearbeitet wird.
 * Nach Abschuss der  Arbeit den Text  in der ehemaligen Leerzeile wieder   entfernen.

Mit diesem Vorgehen ist sichergestellt, dass
 * für andere sichtbar ist, dass der Abschnitt bearbeitet wird und
 * "" unverändert  stehen bleibt, d.h. keine Gefahr einer unbewußten fehlerhaften Änderung.

Dokumentation des Fortschritts der Übersetzung durch farbliche Kodierung der Absätze
Die Absätze der vier Spalten sind farblich kodiert, um den Fortschritt der Übersetzung farblich kenntlich zu machen:
 * Lila (F2CBF8) : Dieser Absatz ist noch nicht übersetzt -> Er muss als erstes  übersetzt werden.
 * Orange (F9CFB5) : Dieser Absatz wurde übersetzt -> Er kann nun kontrollgelesen werden.
 * Gelb (FDE9A9) : Dieser Absatz wurde einmal kontrollgelesen -> Er kann ein zweites Mal  kontrollgelesen werden.
 * Grün (CCF4C6) : Dieser Absatz wurde bereits zweimal kontrollgelesen -> Er kann aber  weiter bearbeitet werden, um Fehler zu beheben oder ihn zu verbessern  (bei größeren Änderungen ist es sinnvoll, ihn zum nochmaligen  Kontrolllesen wieder gelb zu markieren).

Jedes Mal, wenn Du einen Absatz bearbeitet hast, musst Du die Farbkodierung eine Stufe weiter setzten.

In die Kopfzeile eines jeden Absatzes musst du Deinen Namen eintragen, es  muss jeder Absatz von drei verschiedenen Leuten übersetzt und  kontrollgelesen werden.

Englischer Originaltext
Der Englischer Originaltext wird in der jeweiligen Übersertzungs-Wikiseite eingestellt.

Der Originaltext bleibt unterhalb der Übersetzung so lange stehen, bis die erste  Kontrolllesung stattgefunden hat, danach wird er mit     auskommentiert  (nicht gelöscht!).

Mitarbeit protokollieren
Und nicht vergessen: Jeder, der an dieser Übersetzung mitgewirkt hat, sollte sich in die Tabelle der  Übersetzer eintragen, damit sein Engagement auch gewürdigt wird. Dabei bitte darauf achten, dass die Liste alphabetisch sortiert nach den Nachnamen bleibt.

Unklarheiten bzgl. der Übersetzung
Im Zweifelsfall werden mehrere Möglichkeiten ins Wiki gestellt bzw. auf der de-discuss-ML besprochen.

ODT-Erstellung auf ODFAuthors
Die deutschsprachige Benutzerdokumentation wird unter Nutzung der Plattform www.odfauthors.org erstellt. (Hinweis: Die Webseite bzw. das CMS liegt auf einem  Server von OOoDeV/TDF.) Für die Nutzung von ODFAuthors musst Du Dich auf dieser Seite anmelden.

Die verwendete Dokumentvorlage  für die Benutzerdokumentation findet sich hier:   [[Media:LibO3 3 Kapitelvorlage.ott|Kapitelvorlage]].

Vorgehen bei der ODT-Erstellung im Einzelnen:

 * 1) Öffnen der Mustervorlage "XYZ_Kapitelvorlage.ott:
 * Ab LO-Version 4.2 siehe [[File:LibO42_Kapitelvorlage.ott]]
 * LO-Version 4.0 bis 4.1 siehe [[File:LibO4_Kapitelvorlage.ott]]
 * LO-Version 3.3 bis 3.6 siehe [[File:LibO3_3_Kapitelvorlage.ott]]
 * 1) Anpassen der Meta-Daten (ist in der Vorlage beschrieben, wie das geht!)
 * 2) Einfügen der Beteiligten
 * 3) Referenz zum englischen Original und OOo-Dokument

Nach dem Inhaltsverzeichnis:

 * 1) Einfügen der einzelnen Abschnitte (Absätze) mit STRG+C, STRG+ALT+Shift+V (unformatierter Text). Alternativ funktioniert bei mir auch ein Mittelklick (Drücken des Mausrads) für das Einfügen von unformatiertem Text.
 * 2) Zuweisen der entsprechenden Formatierungen
 * 3) Falls Kommentare in der Wiki-Übersetzung vorhanden sind, diese als Kommentar (Einfügen > Kommentar) in das ODT einfügen.
 * 4) Wenn der gesamte Text drin ist, einmal kurz drüberlesen, ob noch irgendwelche offensichtlichen Rechtschreibfehler enthalten sind.
 * 5) Das Dokument ist jetzt soweit vorbereitet, dass es nach ODFAuthors hochgeladen werden kann. Daher Dokument unter Berücksichtigung des Namensschemas (siehe weiter unten) lokal abspeichern.

Hochladen nach ODFAuthors:

 * 1) In ODFAuthors zum Ordner LibreOffice › Deutsch › Arbeitsordner › Entwurf navigieren.
 * 2) Das entsprechende Handbuch auswählen.
 * 3) Menüpunkt Anzeigen > Hinzufügen... > Datei wählen.
 * 4) Titel (z.B. "Kapitel 1 - Einführung in Writer"), kurze Zusammenfassung eingeben, Datei auswählen und unter Änderungsnotiz den aktuellen Bearbeitungsstatus (z.B. "Aus Wiki übernommen") eingeben.
 * 5) Mit Speichern wird dann das Dokument in ODFAuthors hochgeladen.
 * 6) Den Wiki-Status auf DE/Handbuch-Erstellung auf ODFAuthors mit dem Link auf das Dokument in ODFAuthors ändern.

Alle weiteren Änderungen erfolgen jetzt unter Nutzung von ODFAuthors. Insbesondere sind Screenshots einzufügen und die Kommentare abzuarbeiten.

Review- bzw. Änderungs-Prozess auf odfauthors
Nachdem die erste ODT-Fassung erstellt worden ist oder falls auf Basis eines veröffentlichten Kapitels eine neue Version erstellt werden soll, erfolgt die Bearbeitung unter Nutzung von ODFAuthors.

Für eine neue Version eines veröffentlichen Kapitels muss zunächst eine Arbeitsversion erstellt werden. Lade Dir dazu die veröffentlichte Version herunter, benenne die Datei entsprechend dem Namensschema (siehe weiter unten) um und lade die Datei in den Entwurfsordner wieder nach ODFAuthors hoch.

Zum Bearbeiten wie folgt vorgehen (Stand: 23.11.2012):
 * 1) Zu Libreoffice/Deutsch/Arbeitsordner/Entwurf navigieren, danach das entsprechende Handbuch auswählen.
 * 2) Auf den Namen des Kapitels klicken und die Datei damit herunterladen.
 * 3) In der grünen Menüleiste den Status von Interner Entwurf auf Privat ändern. Das "sperrt" die Datei, so dass andere Benutzer sehen, dass jemand daran arbeitet.
 * 4) Heruntergeladene Datei bearbeiten.
 * 5) Nach den Änderungen Datei wieder nach ODFAuthors hochladen: Auf den Eintrag des heruntergeladenen Kapitels gehen und in der grünen Menüleiste Bearbeiten anklicken. Ggf. den Beschreibungstext anpassen. Durch neue Datei ersetzen auswählen. Natürlich nicht vergessen, die Datei auf eurem Computer auszuwählen. Bitte den Namen beibehalten (zur Info: ODFAuthors  hat ein Versionierungssystem wie in einem Wiki). Bitte den Stand des Dokuments unter Änderungsnotiz eingeben und dann Speichern.
 * 6) Die "Sperrung" wieder aufheben indem ihr den Status in der grünen Menüleiste von Privat wieder auf Intern zeigen ändert.

Alternative Anleitung (Stand: 13.09.2011):
 * 1) Zunächst eine Arbeitskopie erstellen (Aktionen -> Arbeitskopie erstellen). Dadurch wird ein neuer Eintrag angelegt (der Eintrag taucht also doppelt in der Liste auf).
 * 2) In die Arbeitskopie kannst du den temporären Stand jederzeit hochladen, so kann sich jeder andere das zwischenzeitlich ansehen. Bietet sich insbesondere an, wenn du über einen längeren Zeitraum alleine ein Dokument bearbeiten möchtest, den anderen den Stand deiner Arbeit mitteilen, aber nicht dazwischengefunkt bekommen möchtest. Während dieser Zeit sollte es für alle anderen unmöglich sein, das Original und die Arbeitskopie zu verändern (funktionierte zuletzt leider nicht).
 * 3) Wenn du fertig bist, lädst du das Dokument in die Arbeitskopie hoch und hebst die Sperrung auf (Aktionen -> Original durch Arbeitskopie ersetzen). Der doppelte Eintrag ist wieder verschwunden und allen das Bearbeiten möglich.

(Ein Review-Prozess ist hier bisher nicht beschrieben. Formales Minimum für ein Review wäre ein Korrekturlesen direkt vor der Veröffentlichung durch eine Person, die nicht an der Erstellung selber - zumindest der letzten Fassung - beteiligt wäre. Sinnvoll wäre es auch festzulegen, was geprüft werden soll. Mir fallen dazu folgende Punkte ein: Inhaltliche/r geeignete/r Struktur/Aufbau des Dokuments, inhaltliche Richtigkeit, Verständlichkeit, einheitliche Verwendung von Begriffen, formale Einhaltung der Vorgaben der Kapitelvorlage, Rechtschreibung. Harald, 23.11.2012)

Namensschema der einzelnen Handbücher
Das Namensschema der einzelnen Handbücher setzt sich aus Bereich, Kürzel für Bereich, Kapitelnummer, Kapitelbezeichnung sowie LO-Version zusammen.

Erklärung am Beispiel "01ES_01LibreOfficeEinführung_V33":
 * 01 -> Bereich (hier: "Erste Schritte" oder Handbuch Nummer 1)
 * ES -> Kürzel für Bereich (= Mnemonic)
 * 01 -> Kapitelnummer
 * LibreOfficeEinführung -> Kapitelbezeichnung
 * V33 -> LO-Version bzw. höchste Softwareversion, für die das Handbuch gilt (hier: Version 3.3)

Deckblätter
Die deutschsprachigen Deckblätter für die Handbücher beruhen auf den internationalen Deckblättern. Aus diesem Grund steht das Design fest. Textänderungen können aber vorgenommen werden.

Ein Überblick sowie die svg-Datei findet sich auf der Wiki-Seite: Deckblätter (deutsch)

Deckblätter für die Kurzanleitungen als [[Media:Kurzanleitung-Cover.svg|SVG]] und als [[Media:Kurzanleitung-Cover.zip|Gesamtpaket (png und svg)]].

Die Deckblätter in der jeweiligen Versionsnummer mit 300dpi gibt es als ZIP-Datei: [[Media:LibO Cover V33.zip|V33]]|[[Media:LibO Cover V34.zip|V34]]|[[Media:LibO Cover V35.zip|V35]].

Bei Verwendung der Deckblätter im Handbuch sollte folgendes unter Mitwirkende ergänzt werden:

und unter: Englisches Originaldokument

Seite 2 -> Absatz "Datum der Veröffentlichung und Softwareversion"
Veröffentlicht am <Datum>. Basierend auf der LibreOffice Version <X.Y>

Die Handbücher werden nicht für jede Softwareversion von LibreOffice aktualisiert. Die Unterschiede zwischen verschiedenen Versionen sind in der Regel aber gering, sodass die Beschreibungen dieses Handbuch-Kapitels in den meisten Fällen auch für vorhergehende und nachfolgende Versionen gültig sind bzw. sein werden.

Seite 2 -> Absatz "Abbildungen"
Dieses Kapitel enthält Abbildungen der Benutzeroberfläche von LibreOffice. Abhängig davon, welches Betriebssystem und welche Betriebssystem-Version Sie benutzen und wie Sie die Benutzeroberfläche des Betriebssystems an Ihre Bedürfnisse angepasst haben, kann die grafische Darstellung der Abbildungen abweichen. Die Funktionen sind aber identisch. Die Abbildungen in diesem Kapitel sind unter <Betriebssystem - z.B. "Windows 7"> erstellt worden.

Allgemeines
Bei der Erstellung von Screenshots besteht das Problem bzw. die Fragestellung, mit welchem Betriebssystem die Erstellung der Screenshots erfolgen soll. Diese Fragestellung wurde vom Board of Directors der TDF am 22.08.2011 diskutiert bzw. es wurde folgende Entscheidung getroffen (s. TDF/BoD Decisions):
 * Screenshots for documentation, website and marketing should preferably be taken on GNU/Linux, but may also be taken on any other operating system.
 * The Steering Committee recommends a consistent visual appearance (e.g. theming and branding) for the screenshots taken on the selected operating system. It is up to the LibreOffice community how to achieve that consistency.

Kommentar:
 * Die Screenshots sollten unter Linux erstellt werden. Das ist aber nicht zwingend. Screenshots unter Windows sind genauso möglich.* Unabhängig davon gilt natürlich, dass das auf Screenshots Gezeigte ebenfalls eine freie Lizenz haben muss. Sprich, einen Screenshot vom Firefox kann man machen. Wird der Screenshot aber erstellt, während auf YouTube gerade ein Konzert von Pink Floyd gezeigt wird, oder in GIMP ein urheberrechtlich geschütztes Bild, ist das nicht gut.
 * Auf LibreOffice bezogen: Die dort gezeigten Dokumente sollten unter einer entsprechenden Lizenz stehen. Dann kann man diese auch abfotografieren.

Screenshot-Erstellung

 * ausgelagert nach /Screenshots

Screenshots (und andere Bilder) einfügen
Nachdem ein Screenshot erstellt ist, muss er richtig in das Dokument eingefügt werden. Am besten geht man wie folgt vor:
 * An der Stelle, wo das Bild später erscheinen soll, einen Absatz mit der Absatzvorlage "LibOAbbildung" formatieren.
 * Cursor in den Absatz setzen.
 * Das Bild z.B. über "Einfügen -> Bild -> Aus Datei..." einfügen.
 * Größe des Bildes einstellen, z.B. über Kontextmenü "Bild...", im Dialog "Bild" dann auf die Registerkarte "Zuschneiden" wechseln (i.d.R. sollten 75% der Originalgröße verwendet werden, es sollte aber noch alles erkennbar sein. Maximal darf das Bild 17,00cm breit sein).
 * Bild "Als Zeichen" verankern, z.B. übers Kontextmenü "Verankerung -> Als Zeichen".
 * Beschriftung hinzufügen, z.B. übers Kontextmenü "Beschriftung...". [Die Verankerung des Bildes geht auf den Rahmen über!!!]
 * Die Beschriftung mit der Absatzvorlage "LibOAbbildungBeschriftung" formatieren.
 * Am Beginn der Beschriftung einen Absatz einfügen.
 * Den neuen Absatz mit der Vorlage "LibOAbbildung" formatieren.
 * Das Bild "Als Zeichen" verankern, z.B. übers Kontextmenü "Verankerung -> Als Zeichen".
 * Den Dialog Rahmen (z.B. übers Kontextmenü "Rahmen...") aufrufen und in den Tab "Typ" wechseln. Hier folgendes einstellen:
 * Breite: "0" (Null) (ändert beim Wechsel ins nächste Feld auf 0,04cm).
 * Option "Automatisch" aktivieren (der Text "Breite" oberhalb ändert sich in "Breite (mindestens)").
 * Höhe: "0" (Null) (ändert beim Wechsel ins nächste Feld auf 0,04cm).
 * Option "Automatisch" aktiviert lassen.

Am Ende sollten also folgende Einstellungen vorliegen:
 * Sowohl der Rahmen, als auch das Bild innerhalb des Rahmens sollten " Als Zeichen " veankert sein und der Absatz, in dem sie sich befinden, jeweils mit der Absatzvorlage " LibOAbbildung " formatiert sein.
 * Der Beschriftungstext sollte die Absatzvorlage " LibOAbbildungBeschriftung " besitzen.
 * Der Rahmen sollte seine Größe (sowohl Höhe als auch Breite) automatisch der des Bildes bzw. des Beschriftungstextes anpassen.

Handbuch "Einsatz von Screenshots in LibreOffice-Handbüchern"
Von Franziska wurde ein Handbuch "Einsatz von Screenshots in LibreOffice-Handbüchern" erstellt. Dieses Handbuch ist als pdf-Dokument in ODF-Authors abrufbar (Leitfaden: http://www.odfauthors.org/libreoffice/deutsch/arbeitsordner/9-hilfsmittel/leitfaden-zum-einsatz-von-screenshots/view bzw. Begründung: http://www.odfauthors.org/libreoffice/deutsch/arbeitsordner/9-hilfsmittel/begrundung-zum-leitfaden/view)

Icon/Symbol-Erstellung

 * Vorbemerkung:
 * Das Aussehen der Icosn/Symbole hängt von dem eingestellten Symbolstil ab.
 * Beispiele für Symbolstile: "Galaxy" (Standard) oder "Crystal".
 * Einigung im April 2012 auf der de-discuss-ML, dass für die Icon/Symbol-Erstellung der Symbolstil "Galaxy" verwendet wird.
 * Vorgehensweise bzgl. der Icon-Erstellung:
 * Die Icons finden sich im folgenden Verzeichnis bzw. entpacke die image*.zip Dateien in \Basis\share\config.
 * Die "command"-Icons befinden sich in res\commandimagelist.
 * Der Präfix "s" bedeutet kleine Bilder.
 * Der prefix "l" bedeutet große Bilder.
 * Die Dateinamen geben einen Hinweis auf das abgespeicherte Icon.
 * Mitwirkende:
 * Florian R. (z.B. Handbuch Draw -> Kapitel 1)

Veröffentlichung
Nach Abschluss aller Änderungen (und nach der Review-Runde?) auf ODF-Authors kann das Dokument veröffentlicht werden.

ODT-Dokument für Veröffentlichung vorbereiten

 * Prüfen, ob es Änderungen gibt, die noch akzeptiert oder verworfen werden müssen. Ggf. akzeptieren oder verwerfen.
 * Prüfen, ob die richtigen Formatvorlagen im Dokument verwendet worden sind.
 * Noch vorhandene Kommentare im Dokument löschen. Falls aufgrund von Kommentaren noch Änderungen vorgenommen werden müssen, kann das Dokument nicht veröffentlicht werden. Wenn die Kommentare für die Bearbeitung einer zukünftigen Version erhalten bleiben sollen, kann man vorher eine Kopie des Dokuments mit einer geänderten Bezeichnung in den Entwurfsordner einstellen.
 * Das aktuelle Datum im Dokument setzen, bzw. aktualisieren.
 * Inhaltsverzeichnis aktualisieren.
 * Die Aufzeichnung von Änderungen aktivieren.
 * Option "Datei schreibgeschützt öffen" setzen (Datei > Eigenschaften > Sicherheit).

PDF-Dokument erstellen
Das PDF-Dokument ist mit den folgenden Optionen (Datei > Exportieren als PDF...) zu erstellen (ist aus der englischen Beschreibung übernommen):
 * Tab Allgemein: "Optimiert für JPEG Komprimierung" auswählen, "Lesezeichen exportieren" wählen, "Standardschriftarten einbetten" wählen.
 * Tab Anfangsdarstellung: "Nur Seite" auswählen, als Vergrößerung "Standard" auswählen, als Seitenlayout "Standard" auswählen.
 * Tab Benutzeroberfläche: "Dokumenttitel anzeigen" wählen, "Alle Lesezeichenebenen" auswählen, alle anderen Optionen sind nicht zu wählen.
 * Tab Verknüpfungen: "Standardverhalten" auswählen. Alle anderen Optionen sind nicht zu wählen.
 * Tab Sicherheit: Hier dürfen keine Kennwörter gesetzt sein.

ODT- und PDF-Dokument hochladen bzw. veröffentlichen

 * ODT-Dokument auf ODFAuthors in hochladen. Dafür den entsprechenden Ordner anhand des jeweiligen Handbuchs und der LibreOffice Version auswählen. Die PDF-Datei wird nicht in ODFAuthors abgelegt.
 * ODT-Datei und dazugehörige PDF-Datei ins Wiki hochladen. Auf der Seite DE/Handbuch-Erstellung Links auf beide Dateien einfügen.
 * Auf der LibreOffice Webseite ebenfalls Links auf beide Dateien einfügen.
 * Auf ODFAuthors im Ordner "Entwurf" entweder das Dokument löschen oder als Basis für eine zukünftige Version kennzeichnen.

Zusammenfassung der einzelnen Kapitel zum Gesamtdokument
(Kochrezept laut Christian)
 * 1) Globaldokument anlegen
 * 2) LibO Vorlage übernehmen
 * 3) Vorspann rein kopieren
 * 4) Deckblatt einfügen
 * 5) Bereiche in den Kapiteln so definieren, sodass Copyright, Inhaltsverzeichnis etc. ausgeblendet werden können
 * 6) Titel und Untertitel in ohne Feldbefehl ändern
 * 7) Kapitel zu Globaldokument hinzufügen
 * 8) Autoren etc. aus Einzelkapiteln zusammenführen
 * 9) Variable setzten, um Bereiche auszublenden
 * 10) drüber scrollen, ob alles richtig aussieht
 * 11) Verzeichnis aktualisieren
 * 12) Veröffentlichungsdatum setzen
 * 13) als ODT exportieren
 * 14) Verknüpfungen lösen
 * 15) als PDF exportieren
 * 16) veröffentlichen

Kenndaten: Mitwirkende und englische Dokumente
Nur für Kapitel, die noch nicht in ODFAuthors eingestellt sind. Bei diesen finden sich die Angaben auf der Erledigt-Seite (siehe DE/Doku/Handbucherstellung %28erledigte Punkte%29

Vorteile

 * Die Übersetzung kann auch in einem sehr kleinen Umfang erfolgen, d.h. kleine Häppchen regen eher zur Mithilfe an
 * Die Übersetzung ist auch ohne Einloggen in eine Plattform sichtbar.
 * Wiki ist "social software" -> Hauptvorteile: hohe Verbreitung, niedrige Zugangsschwelle und gute Akzeptanz.

Nachteile

 * Das Wiki an sich - v.a. das Problem, das man sich etwas mit der Wiki-Gestaltung auskennen muss.
 * Nur ASCII-Text, d.h. es ist keine Formatierung für ein LO-Dokument möglich bzw. hoher (manueller) Aufwand, der beim Konvertieren auftritt. Wenn da ein automatisches 1:1-Konvertieren  möglich wäre, wäre das prima. Dann könnten wir beides  konkurrierend anbieten und könnten die Vorteile beider Paradigmen voll  nutzen. So lange aber der Konvertierungsaufwand eine parallele Nutzung  unmöglich macht, sollten wir pragmatisch sein und das weniger aufwändige  Vorgehen priorisieren.
 * Es fehlt noch die Angabe, welcher Text mit welcher Zeichenvorlage formatiert werden muss (z. B. die eigene Vorlage für Menü-Einträge usw.).
 * Bilder, Screenshots, Tabellen etc. können erst im ODT ordentlich eingearbeitet und referenziert werden. Dadurch ist ein erneutes Bearbeiten notwendig.

Generell

 * Vereinbarung, dass eine Person entweder nur einen Übersetzungsvorschlag oder nur einen  Verbesserungsvorschlag machen kann. Aber nicht beides oder zwei  Verbesserungsvorschläge.
 * Regelmäßige Errinnerung auf der de-discuss-ML, sich an der Übersetzung zu beteiligen.
 * Idee: Texte im Wiki als Dokumentation weiter fertig machen und pflegen, d.h. Bilder ergänzen, die Texte formatieren und ggf. in Tabellen  zurückführen.
 * Eine Wikiseite mit Übersicht über alle Kapitel des Buches mit Übersetzungsstatus (Farbe)
 * Online-Variante, die aus dem Wikitext ein Writer-Dokument macht.
 * Zu OOo-Zeiten war ja schon ein Konverter in Betrieb, der aus Wikseiten ODTs gemacht hat. Die waren aber "nicht gut genug".
 * Möglicherweise kann ein besserer gebaut werden.
 * Weitere, noch nicht erfüllte Anforderungen
 * Irgendeine Form der Übersetzungsunterstützung (Translation Memory oder automatische Vorschläge) wäre wünschenswert

Klärung, wie am besten ein odf-Dokument für Alle bearbeitbar im Netz eingestellt werden kann
Verworfen wurden folgende Ideen:


 * Nutzung von Google Text und Tabellen:
 * Vorschlag von Florian Reisinger (17.06.2011): Beispiel-Link. Hinweis von Florian Reisinger : wer den Link kennt, darf das Dokument bearbeiten. Dadurch kann sich der Inhalt verändern. Nach dem Übersetzen kann man das ändern auf Personen, die einen Google  Account haben, damit nicht irgendwer "zufällig" etwas ändert.
 * Nachteile:
 * Nicht von TDF gehostet
 * Tabellenstruktur ist starr, d.h. es geht z.B. nicht dass in der 1. Zeile eine Zelle und in der 2.Zeile vier Zellen enthalten sind (allerdings kein <k.o.>-Kriterium).
 * Jeder Mitarbeitende muss einen Account bei Google haben - und das will nicht jeder. (Muss man nicht)
 * Möglicherweise hackelig bis unmöglich das Dokument gemeinsam zu bearbeiten. (So einfach wie Writer)
 * Wahrscheinlich gibt es Schwierigkeiten mit den Formatvorlagen. (Im Wiki nicht - oder??)
 * Vorteile:
 * Arbeiten geht leicht von der Hand (Im Unterricht mit bis zu 5 Personen gleichzeitig* getestet).
 * .odt Output
 * Grafiken können eingefügt werden
 * Kann öffentlich oder nur für einzelne Personen freigegeben sein
 * Keine Registrierung notwendig.
 * ECHTES Kollaboratives Arbeiten möglich
 * Rechtschreibprüfung arbeitet schnell
 * (übertreib) WYSIWYG
 * Für jedes Dokument einen "Diskussionsbereich.

Nino Novak (20.06.2011)

 * 1. Konvertieren nach ODF (mit oder ohne Screenshots)
 * 2. Einstellen ins Plone als Entwurf
 * 3. Evtl. noch fehlende Screenshots hinzufügen Damit wäre der Entwurf sozusagen "fertig zum Review", jetzt käme
 * 4. Review-Runde einläuten - für ca. 1 Woche je nach Bedarf
 * 5. Review-Runde beenden und ggf. letzte Änderungen einpflegen.
 * 6. PDF-Konversion mit Gegenlesen
 * 7. Freigabe durch uns und Einstellen  - in odfauthors-Ordner "Veröffentlicht"   - ins Wiki (Documetation/de)   - auf de.libreoffice.org ???

Stefan Haas (20.06.20011)
Ich würde bei der Wiki-Erstellung folgende Änderung vorschlagen:
 * 1.) Derjenige, der die Struktur mit dem englischen Text anlegt, legt für jedes Kapitel einen Threat an, der dieses mitteilt.
 * 2.) Der Erstübersetzer teilt per Antwort-Mail mit, dass die Erstübersetzung für das Kapitel gelaufen ist und zur Erstkorrekturlesung  frei ist.
 * 3.) Derjenige der diese Erstkorrektur vorgenommen hat, teilt den Abschluss dieser mit und sagt außerdem, ob er Korrekturen vorgenommen  hat. Somit ist das Kapitel frei zur Zweitkorrektur.
 * 4.) Derjenige der diese Zweitkorrektur vorgenommen hat, teilt den Abschluss dieser mit und sagt außerdem, ob er Korrekturen vorgenommen  hat. Somit ist die Freigabe des Kapitels erteilt.  Der Vorteil ist hierbei, dass man recht schnell vom Fortschritt der  Übersetzungen und Korrekturen erfährt.

Kommentar:
 * "Abschnitt" = "Bearbeitungsabschnitt", wenn man sich im Wiki eingeloggt hat.

Friedrich Strohmaier (23.06.20011)
Mich hat die Frage beschäftigt, wie man den Export nach odt einfach halten und gleichzeitig mit wenig Aufwand die übersetzte Wikiseite als Onlineversion des Handbuchs stehen lassen kann. Ist doch eigentlich schade drum, wenn die getane Arbeit dafür nicht genutzt werden kann.

Ich habe es auf folgende Weise versucht und den Wikitext - äh - versachlicht: https://wiki.documentfoundation.org/index.php?title=DE/Doku/Allgemein/01_Einf%C3%BChrung&oldid=27376
 * Danach habe ich *die Druckversion* in LibreOffice geöffnet: https://wiki.documentfoundation.org/index.php?title=DE/Doku/Allgemein/01_Einf%C3%BChrung&oldid=27376&printable=yes
 * Alles oberhalb des Inhaltsverzeichnisses und unterhalb der letzten Textzeile entfernt, das Inhaltsverzeichnis aus der Tabelle befreit und das ganze in eine odt-Datei exportiert.
 * Hier das Ergebnis. http://de.libreofficebox.org/static/de/misc/download/Handbuch_Kapitel_1.odt Die Wikiseite habe ich mittels Firefox Add on "It's all text" https://addons.mozilla.org/de/firefox/addon/its-all-text/  in den heimischen Texteditor geladen, was Routineeingriffe (wie das Massenhafte Entfernen der Styleanweisungen) erheblich vereinfacht. (Javascript abschalten!).

Antwort von Jochen: IMHO ist Deine Idee sehr gut. Das Einzige, was ich anders machen würde, wäre Folgendes: Die von Dir "gelöschte" Tabellenstruktur (Einsteller des englischen Originaltextes, Übersetzer etc.) hat zwei Ziele: IMHO ist die Struktur (fast) genial und sollte weiter so behalten werden. Ich denke hier v.a. an Anpassung der Handbücher an kommende LO-Versionen. Mein Vorschlag ist: Dies klingt Alles kompliziert. Ist es vielleicht auch. Aber dass die Erstellung von (deutschsprachigen) Handbüchern nicht einfach ist, hat ja  die diesbezügliche ausführliche Diskussion auf dieser ML gezeigt. IMHO haben wir jetzt einen Weg gefunden, die Erstellung von (deutschsprachigen) Handbüchern zu realisieren und zwar so, dass 1) "jeder" mitmachen kann, 2) häppchenweise vorgegangen werden kann - sowohl die Übersetzung als  auch die Implementierung in ODFAuthor und 3) ein völlige Transparenz vorliegt.
 * 1) Übersicht, wer was gemacht hat und
 * 2) Steuerung des Korrekturlesens.
 * 1) Wiki-Seite mit Tabellenstruktur stehen lassen
 * 2) Unterseiten generieren, die die von Dir beschriebenen Schritte enthalten.
 * 3) Dies kann ja gut über das von mir erstellte Menü gesteuert werden (Stichwort: Erstellung von Untermenüs).

Sigrid Carrera (20.06.2011)
Wollen wir die fertigen Dokumente im Wiki haben? Also als "Wiki-Text" nicht nur als verlinktes odt- oder pdf-Dokument? Ich erinnere mich, dass die englische Gruppe für OOo das versucht hat, hat aber wieder damit aufgehört, weil es doch sehr aufwändig ist. Meine Meinung ist daher:
 * verlinkte odt- und pdf-Dokumente: Ja
 * wikifizierte Texte: Nein

Andreas Mantke (23.06.2011)
Wenn tatsächlich alle gemeinsam an einem Dokument arbeiten wollten (glaube ich erst,  wenn  ich es sehe ;-), dann geht so etwas  nach meiner Kenntnis nur mit einem etherpad  (oder Derivat). Zum Ausprobieren gibt es da Installationen im Netz. Sofern das wirklich das  Tool der Wahl sein sollte, müsste ein Admin das auf einer TDF-Resource   aufsetzen.

Jochen Schiffers (25.06.2011)
ich habe noch einen Vorschlag bzgl. der gemeinsamen Erstellung der Handbücher im odt-Format - und zwar: Dropbox. Ich benutze Dropbox für berufliche Zwecke genau das zu machen, über das wir diskutieren - nämlich gemeinsame Bearbeitung von Dokumenten über das  Internet. Wenn jemand an einem Test Interesse hat, bitte mir Bescheid geben, damit ich das Dokument freigeben kann. Ich würde dann eine Einladung versenden. Hinweis: ein Account bei Dropbox ist nötig. Dieser ist bis 2 GB kostenlos und kann bis 8 GB durch Einladungen erhöht werden.

Kommentar von Erich Christian:
 * Ich auch -> in der Dropbox ist nicht ersichtlich, ob das Dokument gerade von jemand anders bearbeitet wird...
 * Kommentar von Stefan Haas: Das haben wir in der Wiki doch auch gelöst.
 * (sobald es ein zweiter öffnet wird eine 'conflicted copy' generiert, die Änderungen des ersten Bearbeiters bis dahin werden auch nicht unbedingt gespeichert, da Dropbox die neue Version erst erzeugt wenn das Dokument geschlossen wird - und nicht schon beim lokalen Speichern des Editors...
 * Kommentar von Stefan Haas: Das kann man umgehen, indem wir, wie in der Wiki, die einzelnen Punkte in einzelne Dokumente aufteilen.

Kommentar von Stefan Haas:
 * Ich hab mich mal schlau gemacht, die Kritiken der Fachpresse sind überwiegend positiv. Und hinter Dropbox steht kein Moloch, der mittels Patentklagen (auf  Trivialfunktionen)  u.ä. Konkurrenten an die Wand drücken will.