Difference between revisions of "Guidelines (Deutsch)"

(corrected typos , changed bad grammar and removed doublewritten words.)
m
Line 100: Line 100:
  
 
== Spiele ==
 
== Spiele ==
Für Spiele solltest du deine eigene Struktur finden, jedoch solltest du immer diese semantischen Eigenschaften eintragen, damit die Seite korrekt in der [[:Category:Games|Liste der Spiele]] angezeigt wird.
+
Für Spiele solltest du deine eigene Struktur finden, jedoch solltest du diese semantischen Eigenschaften immer eintragen, damit die Seite korrekt in der [[:Category:Games|Liste der Spiele]] angezeigt wird.
  
 
<pre>
 
<pre>

Revision as of 19:34, 24 June 2013

Diese Übersetzung ist nicht bindend! Im Zweifelsfall gilt das englische Original!

Alle registrierten Nutzer dürfen das Wiki bearbeiten, doch bitte beachte die folgenden Richtlinien um Kontinuität zu bewahren. Wenn du denkst, die Richtlinien sollten verändert werden oder zusätzliche Informationen enthalten, zögere nicht Rude zu kontaktieren.

Ziel

Dieses Wiki soll:

  1. Die LÖVE API dokumentieren und Tutorials bereitstellen.
  2. Informationen über Spiele und Bibliotheken, die LÖVE benutzen, bereitstellen.

Es ist durchaus erlaubt Informationen über Dinge, die aus diesen Kategorien fallen, hinzuzufügen.

Wenn du große Änderungen an diesem Wiki machen möchtest, z.B die Struktur der Datentypen ändern: Tu es nicht. Du musst dich vorher mit Rude absprechen, andernfalls wird die Änderung höchstwahrscheinlich widerrufen.

Nameskonflikte

Um zu viele Klammern in den URLs zu vermeiden haben die Dokumentationsseiten klare Titel ohne Präfix oder Suffix. Zum Beispiel kann der Typ Image extern über http://love2d.org/wiki/Image referenziert werden.

Das kann z.B. zu Namenskonflikten führen, bei den die Dokumentationsseiten immer gewinnen. Wenn du ein Spiel namens Awesome erstellst und LÖVE später einen Typ namens Awesome einführt (was nicht komplett ausgeschlossen ist), so wird diese Seite der deines Spiel vorgezogen.

Style

Wenn du über in LÖVE eingebaute Typen schreibst, verlinke sie auch. So ist Image beispielsweise ein Objekt, welches auf dem Bildschirm dargestellt werden kann.

Wenn du in einem normalen Satz auf Variablen oder Code verweist, nutze das <code> Tag, um die Lesbarkeit zu verbessern. z.B.: wenn du foo und bar addierst, erhältst du foobar.

Dokumentation

Dokumentationsseiten müssen alle die selbe Struktur aufweisen, wenn die Dokumentation benutzbar sein soll.

Alle Dokumentationsseiten müssen einen semantischen Link zu übergeordneten Seiten in ihrer Siehe auch-Sektion aufweisen. Ohne erscheint die Seite nicht in den automatischen Listen des Wikis. Ein semantischer Link wie dieser findet sich in allen Funktionen, Typen oder Enums von love.audio:

[[parent::love.audio]]

Alle Dokumentationsseiten brauchen außerdem eine semantische, 'listenfreundliche' Beschreibung. Diese erstellt man durch folgende Zeile am unteren Ende der Seite:

{{#set:Description=Zeichnet [[Image|Bild]] auf den Bildschirm}}

Module

Die folgenden 'Ebene 2' Überschriften sind erlaubt, sollten aber nur erstellt werden, wenn sie auch etwas beinhalten.

  • Typen
  • Funktionen
  • Enums
  • Anmerkungen
  • Beispiele
  • Siehe auch

Alle Module müssen mit Category:Modules assoziert werden.

Typen

Die folgenden 'Ebene 2' Überschriften sind erlaubt, sollten aber nur erstellt werden, wenn sie auch etwas beinhalten.

  • Funktionen
  • Enums
  • Basistypen
  • Subtypen
  • Anmerkungen
  • Beispiele
  • Siehe auch

Alle Module müssen mit Category:Types assoziert werden.

Functions

Bei Funktionen müssen alle Überschriften, außer Anmerkungen, Beispiele und Siehe auch, vorhanden sein. Das heißt, wenn eine Funktion keinen Rückgabewert hat, sollte das explizit geschrieben werden. Dasselbe gilt für Argumente.

Wenn es für einen bestimmten Typ keinen Konstruktor gibt (z.B. Contact), sollte das explizit erwähnt werden.

  • Konstruktoren
  • Funktionen
    • Zusammenfassung
    • Argumente
    • Rückgabewerte
  • Anmerkungen
  • Beispiele
  • Siehe auch

Wenn die Funktion überladen ist, wiederhole den Funktionsabschnitt für jede Überladung. Bei optionalen, abschließenden Argumenten muss das nicht getan werden. Weise einfach auf den Standardwert hin.

Argumente und Rückgabewerte sollten mithilfe von Template:param als Definitionsliste dargestellt werden.

Alle Funktionen müssen mit Category:Functions assoziert werden.

Enums

Bei Enums sind folgenden Überschriften erlaubt:

  • Konstanten
  • Anmerkungen
  • Siehe auch

Die Konstanten sollten als Definitionsliste aufgelistet werden.

Alle Enums müssen mit Category:Enums assoziert werden.

Spiele

Für Spiele solltest du deine eigene Struktur finden, jedoch solltest du diese semantischen Eigenschaften immer eintragen, damit die Seite korrekt in der Liste der Spiele angezeigt wird.

{{#set:Name=NoGame}} (Sollte dem Seitennamen entsprechen)
{{#set:Author=User:Rude}}
{{#set:Genre=Der Typ des Spiels}}
{{#set:LOVE Version=0.6.1}}
{{#set:Description=Eine kurze Spielbeschreibung.}}
{{#set:Screenshot=File:ScreenshotURL.png}}

Screenshots werden automatisch skaliert um in eine 161x100 Pixel Box zu passen.

Stelle das Spiel unter Category:Games, damit es automatisch in der Spieleseite erscheint. Füge dazu diesen Text an das Ende der Seite:

[[Category:Games]]

Es ist außerdem empfohlen Screenshots deines Spieles bereitzustellen.

Bibliotheken

Hier gibt es auch keine strikten Regeln, dennoch solltest du genau wie bei Spielen die folgenden semantischen Eigenschaften einbringen:

{{#set:LOVE Version=0.6.1}}
{{#set:Description=Eine kurze Beschreibung der Bibliothek.}}

Stelle die Bibliothek unter Category:Libraries, damit sie automatisch in der Bibliothekenseite erscheint. Füge dazu diesen Text an das Ende der Seite:

[[Category:Libraries]]