Konzept für die Handbucherstellung

From The Document Foundation Wiki
< DE‎ | Doku
Jump to: navigation, search

Contents

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 (erledigte Punkte) 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".

Konzept bzw. Vorgehensweise (Langfassung)

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:

  • Leere Absätze löschen.
  • Absätze als Code formatieren:
    • Suchen & Ersetzen (Reguläre Ausdrücke aktivieren!!!): $ ersetzen durch </code>\n\n<code>
    • Beim ersten Absatz noch <code> und beim letzten Absatz </code> 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: <code>\* ersetzen durch *<code>
    • Suchen & Ersetzen: <code># ersetzen durch #<code>
    • Suchen & Ersetzen: <code>; ersetzen durch ;<code>
    • Suchen & Ersetzen: <code>: ersetzen durch :<code>
  • 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: ^; und folgende Leerzeile manuell löschen. (s.o.)
  • Code aus Überschriften entfernen:
    • Suchen & Ersetzen: <code>= ersetzen durch =
    • Suchen & Ersetzen: =</code> ersetzen durch =
  • Tabellen einfügen:
    • Suchen und Ersetzen: =$ ersetzen durch = <!-- {{Template:Translation in Progress/de}} -->\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: ^= ersetzen durch |}\n\n=
      • Bei der ersten Überschrift nicht ersetzen oder wieder löschen.
      • Nach dem letzten Absatz noch manuell ergänzen.

Textdokument ins Wiki kopieren

Feingranulierte Multiautoren-Übersetzung im Wiki

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:

Translation in Progress! - Dokument/Abschnitt wird gerade übersetzt!
Bitte abwarten oder - in Absprache - mithelfen, aber nicht einfach dazwischenfunken ;)

  • Im Quelltext ist für jeden Abschnitt <!-- {{Template:Translation in Progress/de}} --> vorab eingetragen. Kopiere aus diesem Text {{Template:Translation in Progress/de}}
  • Füge {{Template:Translation in Progress/de}} 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 {{Template:Translation in Progress/de}} 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 <!-- (Text des Absatzes) --> 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: Kapitelvorlage.

Erste ODT-Fassung der Übersetzung erstellen

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
  2. Anpassen der Meta-Daten (ist in der Vorlage beschrieben, wie das geht!)
  3. Einfügen der Beteiligten
  4. 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 Documentation/de 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)


Titel Version Bemerkungen
LibreOffice allgemein
Deckblatt PNG | LibO Cover KA LibO.png Design: K-j (talk)
Extension LanguageTool ODT | PDF Autor: K-j (talk)
Writer
Deckblatt PNG | LibO Cover KA Writer.png Design: K-j (talk)
---
Calc
Deckblatt PNG | LibO Cover KA Calc.png Design: K-j (talk)
Datenpilot ODT | PDF Autor: K-j (talk)
Draw
Deckblatt PNG | LibO Cover KA Draw.png Design: K-j (talk)
---
Impress
Deckblatt PNG | LibO Cover KA Impress.png Design: K-j (talk)
---
Base
Deckblatt PNG | LibO Cover KA Base.png Design: K-j (talk)
---
Math
Deckblatt PNG | LibO Cover KA Math.png Design: K-j (talk)
---

Deckblätter für die Kurzanleitungen als SVG und als Gesamtpaket (png und svg).


Die Deckblätter in der jeweiligen Versionsnummer mit 300dpi gibt es als ZIP-Datei: V33|V34|V35.

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

Deckblattgestaltung (deutsch)
Klaus-Jürgen Weghorn

und unter: Englisches Originaldokument

internationale Deckblätter
Drew Jensen Christoph Noack Jean Weber Klaus-Jürgen Weghorn


Texte, die in jedem Handbuch gleich erscheinen

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.

Screenshot-Erstellung

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
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 <installation>\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 Documentation/de 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 (erledigte Punkte)

Erste Schritte Handbuch

Einführung Kapitel 13 (Einführung in Makros)

Buchtitel Erste Schritte
Kapitel Kapitel 13 - Einführung in Makros
Mitwirkende

Ralf Albrecht
Erhardt Balthasar
Christian Kühl ()
Nino Novak
Jochen Schiffers
Klaus-Jürgen Weghorn (k-j)

englisches Original

Ron Faile Jr.

OpenOffice.org Original

Andrew Pitonyak
Jean Hollis Weber

Writer Handbuch

Writer Kapitel 02 (Writer-Einstellungen)

Buchtitel Writer Handbuch
Kapitel Kapitel 02 - Writer-Einstellungen
Mitwirkende

Erhardt Balthasar
Klaus-Jürgen Weghorn (k-j)
Andreas Gärtner

englisches Original

John M. Długosz
Ron Faile Jr.
Hal Parker

OpenOffice.org Original

Jean Hollis Weber
Agnes Belzunce
Daniel Carrera
Peter Hillier-Brook
Stefan A. Keel
Gary Schnabl
Janet M. Swisher
Michele Zarri
Jared Kobos

Writer Kapitel 03 (Arbeiten mit Text)

Buchtitel Writer Handbuch
Kapitel Kapitel 03 - Arbeiten mit Text
Mitwirkende

Erhardt Balthasar
Klaus-Jürgen Weghorn (k-j)
Andreas Gärtner

englisches Original

John M. Długosz
Ron Faile Jr.
Hal Parker

OpenOffice.org Original

Jean Hollis Weber
Agnes Belzunce
Daniel Carrera
Peter Hillier-Brook
Laurent Duperval
Katharina Greif
Michael Kotsarinis
Peter Kupfer
Iain Roberts
Gary Schnabl
Barbara M. Tobias
Michele Zarri
Sharon Whiston

Writer Anhang A (Tastaturkürzel)

Buchtitel Writer Handbuch
Kapitel Anhang A Tastaturkürzel
Mitwirkende

Erhardt Balthasar
Jochen Schiffers
Klaus-Jürgen Weghorn (k-j)

englisches Original

Ron Faile Jr.
Barbara Duprey

OpenOffice.org Original

Magnus Adielsson
Peter Hillier-Brook
Peter Kupfer
Jean Hollis Weber
Michele Zarri
Alexander Noël Dunne

Calc Handbuch

Calc Kapitel 01 (Einführung in Calc)

Buchtitel Calc Handbuch
Kapitel Kapitel 01 - Einführung in Calc
Mitwirkende

Erhardt Balthasar
Andreas Gärtner
Christian Kühl
Klaus-Jürgen Weghorn (k-j)

englisches Original

Barbara Duprey
Hal Parker

OpenOffice.org Original

Rick Barnes
Nicole Cairns
Peter Kupfer
Jean Hollis Weber
Krishna Aradhi
Andy Brown
Alexandre Martins
Anthony Petrillo
Gary Schnabl
Barbara M Tobias

Calc Kapitel 02 (Eingabe, Änderung und Formatierung von Daten)

Buchtitel Calc Handbuch
Kapitel Kapitel 02 - Eingabe, Änderung und Formatierung von Daten
Mitwirkende

Christian Kühl
Klaus-Jürgen Weghorn (k-j)
Franziska Schulthess

englisches Original

Barbara Duprey
Hal Parker

OpenOffice.org Original

Andy Brown
Stephen Buck
Jared Kobos
Peter Kupfer
Iain Roberts
Hazel Russman
Barbara M. Tobias
Jean Hollis Weber


Impress Handbuch

Impress Kapitel 01 (Einführung in Impress)

Buchtitel Impress Handbuch
Kapitel Kapitel 01 - Einführung in Impress
Mitwirkende

Klaus-Jürgen Weghorn (k-j)

englisches Original

Michele Zarri
T. Elliot Turner
Jean Hollis Weber
Chad D. Lines
Low Song Chuan
Muhammad Sufyan Zainalabidin
Jaimon Jacob

OpenOffice.org Original

Michele Zarri
Jean Hollis Weber
Dan Lewis
Agnes Belzunce
Peter Hillier-Brook
Gary Schnabl
Claire Wood
Rachel Kartch
Hazel Russman
Linda Worthington

Tim Kampa, Charles Fannan, and Dana Oliver, students in the Technical and Professional Writing Program at San Francisco State University, wrote a previous version of this document for OpenOffice.org 1.1 (copyright Tim Kampa).


Draw Handbuch

Draw Kapitel 01 (Einführung in Draw)

Buchtitel Draw Handbuch
Kapitel Kapitel 01 - Einführung in Draw
Mitwirkende

Klaus-Jürgen Weghorn (k-j)

englisches Original

Martin Fox
John Cleland
Jean Hollis Weber

OpenOffice.org Original

This chapter is based on an original French document written for OpenOffice.org 1.x by Michel Pinquier (translated into English by Alex Thurgood) and previous content revised by Jim Taylor. The chapter was revised for OpenOffice.org 2.0 by Linda Worthington, Daniel Carrera, Jean Hollis Weber, and Agnes Belzunce, and later translated into German by Wolfgang Uhlig. The German revisions were then translated into English and revised for OpenOffice.org 3.3 and LibreOffice 3.3 by Martin Fox. Other contributors included Peter Hillier-Brook, Hazel Russman, Gary Schnabl, and Claire Wood.

Bewertung des Konzeptes bzw. der Vorgehensweise

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.

Schätzung des Arbeitsaufwandes

Nr. Arbeitsschritt Zeitaufwand Bemerkungen Kommentare (mit Namen)
1 englisches Original-ODT besorgen kurz
2 Originaltext ins Wiki stellen 1 Stunde pro Kapitel
  • Workaround vorhanden (s.u.)
3 Übersetzen der Abschnitte ca. 5-30 min/Abschnitt Nino: ist mir zu feingranuliert, ich verliere den Überblick
Jochen: finde Farblösung ideal, gebe aber zu, dass "Farbspiel" und Aufteilung persönliche Geschmacksache sind. Vorschlag: Personen, die damit nicht zurecht kommen, übersetzen separat und posten Text an de-discuss-ML oder per PM an Personen, die den Text im Wiki einpfelgen.
Kü: @Nino: Halte ich nicht für sinnvoll. Besser mehrere Abschnitte in Folge mit Template versehen und dann auf einmal abarbeiten (aber auch in überschaubarer Zeit (einige Stunden) dann erledigen).
4 Korrekturlesen 1 5-20 Minuten pro Abschnitt
  • Originaltext auskommentieren
Jochen: 5 Minunten bei einem einfachen Sachverhalt bzw. 20 Minunten bei einem schwierigen Sachverhalt.
5 Korrekturlesen 2 5-10 Minunten pro Abschnitt
6 Abschließen der Übersetzung
  • Fertigstellung hier vermerken
  • E-Mail an Mailingliste
Hm, was ist denn damit gemeint? Ich habe auf der Mailingliste gefragt, ob die Übersetzung fertig ist und als ich da ein "Ja" hörte, habe ich damit angefangen, den Text in die .odt-Vorlage zu kopieren.
Genau das: Ob wir sozusagen "explizite Freigabebedingungen zum Übertragen" festlegen wollen, etwa (Vorschlag): "Wenn alle Abschnitte grün sind, kann mit der Übertragung begonnen werden". Dann kann die Kommunikation in der Liste auf die Mitteilung "Kapitel X: Übertragung begonnen" reduziert werden, eine Rückfrage ist quasi nicht mehr nötig. (Hintergedanke: Je expliziter wir die Prozesse festlegen, und je simpler diese Festlegungen sind, desto flüssiger läuft der Gesamtprozess)
Nino 2011-07-04T14:26:18 (CEST)
7 Vorbereiten des ODT aus Vorlage 5 Minuten
  • E-Mail an Mailingliste
  • Beginn hier vermerken
  • Vorlage öffnen, Eigenschaften bearbeiten, abspeichern
  • Auf ODF-Authors hochladen, um Eintrag zu erstellen
8 Übertragen der übersetzten Abschnitte ins ODT ca. 5 Minuten pro Abschnitt
  • Text abschnittsweise als unformatierten Text einfügen
Ich hab das beim Kapitel 3 jetzt mal "auf einmal" versucht, also nicht Abschnitt für Abschnitt, sondern die gesamte Wikiseite auf einemal markiert und ins Dokument gepastet. Das ging im Prinzip gut, aber ich weiss nicht, wie empfehlenswert das ist, kann mich auch nicht mehr erinnern, ob dabei was zu beachten ist (ich habs einfach "unbewusst" so gemacht, ohne deine Vorgehensweise hier im Einzelnen durchgelesen zu haben). Bestimmt bringt Christian noch eine weitere Variante ein ;-)
Nino 2011-07-04T14:26:18 (CEST)
9 Screenshots erstellen und einfügen mit Bildbeschriftungen ca. 10 - 15 Minuten pro Bild
  • Hinweise für Screenshots beachten
Hängt davon ab, wie aufwändig das Bild nachbearbeitet werden muss (Pfeile einfügen um auf spezielle Icons hinzuweisen, usw.)
10 Reviewrunde in ODFAuthors 1 - (viele) Stunden Hängt davon ab, wie umfangreich das Dokument ist, wie intensiv man sich damit beschäftigt und wie gut das Dokument schon vorbereitet ist.
11 PDF-Erstellung und Veröffentlichung 30 Minuten
  • Datum setzen
  • PDF erstellen
  • ODT und PDF nach ODFAuthors in Sektion "Veröffentlicht" hochladen
  • ODT und PDF ins Wiki hochladen
  • Wiki mit Dateien verknüpfen (hier)
  • Auf der LibreOffice Webseite Links einfügen


Ideen und Verbesserungsvorschläge

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

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:

  • 1) Übersicht, wer was gemacht hat und
  • 2) Steuerung des Korrekturlesens.

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:

  • 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).

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.

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.