Regeln

Regeln

Grund- und Verhaltensregeln

1. Seid einfach nett zueinander, respektvoll, konstruktiv, und geht immer vom Besten aus.
2. Es ist nicht gestattet, Geld für Dienste, die in irgendeiner Form das Wiki betreffen, zu nehmen. Insbesondere ist es untersagt, Geld für Hilfe beim Schreiben von Artikeln oder für Feedback allgemein zu nehmen. Dies wird mit einem mindestens einjährigen Bann für den Geldnehmer belegt. Content-Creator, also Ersteller von Artworks, Vertonungen usw., sind für diese Werke nicht von dieser Regel betroffen. Davon gibt es keine Ausnahme.
3. SCPs sind nicht echt.
4. Bitte kein Rollenspiel betreiben.
5. Wir behalten uns vor, bei guten Gründen Ausnahmen von allen Regeln, bei denen dies nicht ausdrücklich ausgeschlossen ist, zuzulassen.
   • Jede Ausnahme ist eine Einzelfallentscheidung und keine Argumentationsbasis für spätere Ausnahmeersuchen.
   • Wird eine Ausnahme genehmigt, ist zu prüfen in wie weit dieser einer Regeländerung folgen sollte.
   • „Gute Gründe“ sind zum Beispiel Mängel in den Regeln oder Sonderfälle die von den Regeln nicht direkt abgedeckt werden, für die eine schnelle Lösung benötigt wird. „Gute Gründe“ sind rein objektiv.
   • Ausnahmen werden nur bei Dingen erteilt, die keine Auswirkungen auf andere Fälle haben, und die nicht zu einer Ungleichbehandlung von Usern führen. Schwerwiegende oder kontroverse Ausnahmen bedürfen einer Änderung des Regelwerks.
6. Alle User sind aufgerufen, Feedback und Kritik zu existierenden Artikeln und Entwürfen im Forum zu geben.
   • Alles Feedback und Kritik sollte ausgewogen sein, sachlich, hilfreich und Negatives mit Positivem aufwiegen.
7. Alle User sollen Artikel ehrlich bewerten.
   • Die Bewertung ist anonym, wird jedoch bei Vandalismusverdacht von Admins überprüft.
   • Gerade wenn ihr einen Artikel negativ bewertet, wird es überaus geschätzt, wenn ihr auch Feedback gebt.
8. In allen Fällen, in denen die Regeln widersprüchlich, unklar, oder undefiniert sind, gilt die ungeschriebene Regel #1: Sei kein Arsch!
   • Es wird gebeten, solche Fälle zu melden, dann werden die Regeln korrigiert bzw. über den vorliegenden Fall beratschlagt.
9. Alles, was nicht in diesem Artikel steht, ist keine verbindliche Regel.
10. Alle User sind dazu aufgerufen, diese Regeln auf Fehler, Unklarheiten, und mögliche Verbesserungen hin zu überprüfen, und Änderungen vorzuschlagen.
11. Allen mit über normale Nutzerrechte hinausgehenden Rechten (Admins, Moderatoren, Beauftragte) ist es verboten, diese Rechte für persönliche Zwecke zu missbrauchen. Die Community hat dagegen aufzubegehren.

• Alle Begriffe in diesem Regelwerk sind geschlechtsunspezifisch; es sind stets alle Personen jeden Genders gemeint.
• Alle Regeln bezüglich gesetzlicher oder lizenztechnischer Regelungen sind ohne Gewähr.

• Non-German speakers can find rules in English here.

Wiki-Mitgliedschaft

1. Das Mindestalter im Wiki und im Chat beträgt 14 Jahre. Davon gibt es keine Ausnahme.
2. Die Mitgliedschaft in diesem Wiki erfordert, diese Regeln sowie die Rechtliche Erklärung gelesen zu haben und zu akzeptieren.
3. Die Mitgliedschaft für dieses Wiki kann bei Regelverstößen jederzeit widerrufen werden und ein zeitlich begrenzter oder permanenter Bann erfolgen.
   • Die Auslegung der Regeln und die Evaluation des Regelverstoßes erfolgt durch die Administration.
   • Entscheidungen der Vergangenheit stellen keine Präzedenz dar; alle Entscheidungen sind Einzelfallbetrachtungen.
   • Etwaige Disziplinarrichtlinien sind Leitfäden und keine Regeln.
4. Das Pɑsswοrt um dem Wiki beizutreten lautet Goldfisch (ohne Leerzeichen dahinter!).
   • Das Pɑsswοrt für die Sɑndbοx steht weiter unten in den Regeln. Lies alles um es zu finden.

Allgemeine Artikelregeln

Inhalt
Grundlegende Regeln
Existierende Artikel
Artikel löschen
Medien
Elternseiten
Themes und CSS

Grundlegende Regeln für Artikel aller Art

1. Alle Artikel mit SCP-Bezug sowie darin eingebettete Werke wie Bilder werden hier unter der Creative Commons Attribution-ShareAlike 3.0 License veröffentlicht. Davon gibt es keine Ausnahmen.
2. Alle Inhalte haben für eine frei zugängliche Webseite geeignet zu sein. Es findet keine Alterskontrolle beim Zugang zum Wiki statt. Jugendschutzmechanismen sind aufgrund technischer Einschränkungen nicht möglich.
3. Alle Artikel, die keine Systemartikel, Portal-, Autoren- oder Artworkseiten sind, sind mit dem Bewertungsmodul auszustatten, siehe Hilfe, Tab „Code-Blöcke”.
4. Jeder Artikel ist mit Credits (Autor, Bildquellen, Lizenzen usw.) zu versehen, in den Kommentaren und/oder mit dem Credit-Modul.
5. Alle Artikel sind mit Tags zu versehen. Beachte zwingend die Tagregeln weiter unten!
6. Es sind ausschließlich fertige, korrigierte, und den Regeln für neue Artikel und Übersetzungen entsprechend hergestellte Artikel im Wiki zu veröffentlichen.
7. Autoren, die externe Medien oder Code einbetten, sind verpflichtet die anbietende Seite auf deren Datenschutzregelungen zu prüfen und ggf. eine Datenschutzerklärung nach DSGVO abzugeben! Dies ist keine Bitte, sondern gesetzlich vorgeschrieben!
   • Es wird dringend empfohlen, Code nur im Wiki selbst oder auf Plattformen die keine nicht notwendigen Daten sammeln hochzuladen, wie z.B. GitHub.

Existierende Artikel

• Die Regeln dieser Sektion sind unabhängig vom geistigen Eigentum und tatsächlichen Eigentumsverhältnissen zu betrachten.

1. Der Autor besitzt für die Zeit von dessen aktiver Mitgliedschaft grundsätzlich die Entscheidungsgewalt über seine Artikel im Rahmen dieser Regeln.
   • Kommt jedoch die Community in einer Abstimmung zu dem Schluss, dass Änderungen nötig sind, kann sie den Autor überstimmen. Diese Abstimmung erfolgt im Abstimmungskanal. Neben der Mehrheit aller Teilnehmer, muss eine Mehrheit der Freigabeberechtigten mit einem Quorum von 60% dafür stimmen. Die Administratoren können gegen die Abstimmung votieren, wenn Manipulation im Raum steht.
2. Artikel wie die Hubs von Interessengruppen, Kanons, und kanonische Hintergrundartikeln, gelten als moderiertes Community-Eigentum; Änderungen geschehen nach allgemeinem Konsens der daran Interessierten.
3. Ist ein Autor zwei (2) Jahre inaktiv, gelten diese Artikel als Community-Eigentum.
   • Dies bedeutet, dass Änderungen oder Neuauflagen ohne Zustimmung des Autors in Absprache mit der Community stattfinden können.
4. Sofern es nicht offensichtlich ist oder aus Kommentaren hervorgeht, dass diese beabsichtigt sind, dürfen grundsätzlich alle Rechtschreib- und Grammatikfehler korrigiert werden.
   • Dies darf nicht zu einer Umstrukturierung eines Satzes oder möglicher Sinnveränderung führen.
   • Größere Korrekturen sind mit dem Autor/Übersetzer abzusprechen, oder bei dessen Inaktivität mit der Community.
5. Neuauflagen durch den Autor/Übersetzer oder, bei dessen Inaktivität, durch Dritte, erfordern stets eine Neuvorlage im Feedback-Forum und ein erneutes Durchlaufen des Feedbackprozesses.
6. Jeder kann Fehler in Tags korrigieren, und fehlende erforderliche Tags ergänzen. Attribut-Tags werden außer bei Übersetzungen nur vom Autor gesetzt.

Artikel löschen/Autorenschaft widerrufen

• Gemäß dem deutschen Urheberrecht hat jeder Urheber das Recht auf Löschung seines Werks.
• Gemäß der CC BY-SA 3.0 Lizenz hat jeder Urheber eines Werks das Recht auf Widerruf der Attribution.
• Gemäß der CC BY-SA 3.0 Lizenz hat jeder, der eine Kopie eines so lizensierten Werkes besitzt, das Recht, dieses wieder zu veröffentlichen.

1. Während seiner Mitgliedschaft steht es dem Autor frei, seinen Artikel zu löschen.
2. Nach seiner Mitgliedschaft, werden Artikel auf Wunsch des Autors gelöscht.
3. Es steht jedem Autor frei, die Autorenschaft zu einem Artikel zu widerrufen, etwa um sich von dem Artikel zu distanzieren.
   • Dieser wird dann mit einem anonymen Platzhalter-Account neu gepostet.
4. Sinkt die Bewertung eines Artikels auf -7 oder niedriger, wird die Löschung des Artikels anberaumt. Es kann eine Neuauflage in Betracht gezogen werden, sofern daran Interesse bekundet wird.
5. Artikel welche rechts- oder regelwidrig sind, werden gelöscht.
6. Eine Löschung von Artikeln aus disziplinarischen Gründen findet nicht statt.

Medien

1. Beachte zwingend die Medienlizenzierungsregeln und Regeln zum Setzen von Medien-Tags!
2. Bitte lade nur Medien mit einer Größe von maximal 1 MB hoch. Wir haben nur 300 MB Speicherplatz im Wiki zur Verfügung.
   • Verwende für große oder viele Medien bitte externe Dienste. Beachte dabei deren Datenschutzerklärung!
   • Bedenke, dass große Dateien die Ladezeit der Seite erhöhen und Datenvolumen eurer Leser verbrauchen.
   • Es wird empfohlen, Medien so weit zu verkleinern, auch von der Auflösung her, wie es ihre Darstellung im Wiki gerade eben erfordert. Größere, extern gespeicherte Versionen des Mediums können per Verknüpfung durch Anklicken geöffnet werden.
3. Sofern nichts dagegenspricht, ist standardmäßig der Image-Block zu verwenden, siehe Hilfe, Tab „Code-Blöcke”.
4. Medien in Übersetzungen sollten aus dem Originalwiki verlinkt werden, anstatt sie bei uns hochzuladen.

Elternseiten

1. Alle Artikel sollen immer mit Elternseiten versehen werden, zwecks vereinfachter Navigation.
2. Bei Anhängen und Fragmenten ist immer der Hauptartikel als Elternseite zu setzen.
3. Bei anderen Artikeln sollte die Portalseite, in der sie primär aufgelistet sind, gesetzt werden.
4. Fehlende Elternseiten dürfen von jedem ergänzt werden.

Themes und CSS

1. Beachte zwingend die Coderegeln!
2. Die Verwendung von CSS und Themes, welche das Sigma-9-Theme sichtbar verändern, ist nicht gestattet, außer unter folgenden Ausnahmen:
   • Es ergibt in-universe Sinn (zum Beispiel bei Kanon-Seiten, GOI-Formaten oder Witz-Artikeln).
   • Es handelt sich um kleine, nicht oder kaum sichtbare Bugfixes oder Verbesserungen (bitte mit Dr_Grom absprechen).
   • Es handelt sich um eine Autoren- oder Artworkseite, oder zum Theme gehörende Seiten.
   • Es handelt sich um Elemente innerhalb des Artikels, also der Inhalt von <div id="page-content">, <div id="page-title"> und <div id="breadcrumbs">. Z.B. ein anderes Format für die graue Box. Diese sind als Stilmittel zu betrachten. Dabei zu fancy zu werden ist jedoch nicht empfohlen.
   • Es handelt sich um das Theme einer Übersetzung, dessen Übernahme vom Autor des Originalartikels mit einer Begründung, die über bloße Präferenz hinaus geht, ausdrücklich gewünscht wurde und dessen Code mit dem hier verwendeten Standard-Theme kompatibel ist. (Also keine falsch formatierten Navigationselemente oder sowas erzeugt.)
3. Seiten, welche (regelkonform) ein Theme verwenden, sind mit _theme zu taggen, damit das Theme überprüft und gegebenenfalls Bugs korrigiert werden können.
4. Zur Erstellung von Themes, und Code im Allgemeinen, sind die untenstehenden Coderegeln zu beachten.

Neue Artikel

Inhalt
Artikel schreiben
Artikel vorstellen
Freigaben
Nach der Veröffentlichung

Siehe auch SCP-Guide für Anfänger und Neueinsteiger und Wie schreibt man ein SCP.

Neue Artikel schreiben

1. Neue Artikel sollen selbst verfasst sein.
2. Es ist dringend empfohlen, bevor du einen Artikel schreibst, das Konzept vorzustellen und dir Feedback dafür zu holen.
   • Auch bei fertigen Entwürfen soll das Team zunächst das Konzept betrachten.
3. Neue SCPs bekommen eine Nummer, die zum Zeitpunkt der Veröffentlichung frei ist.
   • Eine Reservierung einer Nummer ist nur in Ausnahmefällen möglich.
4. Neue Artikel müssen in der Sandbox vorbereitet werden.
   • Nicht freigegebene Artikel, die im Hauptwiki gepostet werden, werden gelöscht und der Autor für eine Woche gebannt.
5. Die Verwendung von CSS und Themes, welche das Sigma-9-Theme sichtbar verändern, ist nicht gestattet, außer es ergibt in-universe Sinn (zum Beispiel bei Kanon-Seiten, GOI-Formaten oder Witz-Artikeln), es handelt sich um kleine, nicht oder kaum sichtbare Bugfixes oder Verbesserungen oder es handelt sich um eine Autoren- oder Artworkseite, oder es handelt sich um Elemente innerhalb des Artikels, also der Inhalt von <div id="page-content">, <div id="page-title"> und <div id="breadcrumbs">. Z.B. ein anderes Format für die graue Box. Diese sind als Stilmittel zu betrachten. Dabei zu fancy zu werden ist jedoch nicht empfohlen.

Einen Artikel vorstellen

1. Vor der Vorstellung eines Entwurfs, und nach größeren Änderungen, ist dieser mit einer Rechtschreibprüfungssoftware (z.B. gängiger Office-Software) zu rechtschreibprüfen.
2. Entwürfe sind in einem Thread im Feedback-Forum vorzustellen.
   • Entwürfe bitte nicht direkt in einen Forenpost packen, sondern deine Sandbox verlinken.
3. Es ist stets nur ein aktiver Thread pro User erlaubt.
   • Wenn du ein Projekt unter- oder abbrichst, schreib das bitte deutlich sichtbar hinein.
   • Alle Threads die länger als 60 Tage inaktiv sind, werden in das Feedback-Archiv verschoben und auf Wunsch wieder hervorgeholt.
   • Abgebrochene Threads werden ganz archiviert. Bitte schreibe daher den richtigen Status in deinen Thread. Auch diese können wiederhergestellt werden.
4. Alle User sind aufgerufen, zu existierenden Artikeln in den Kommentaren, und zu Entwürfen im Feedbackforum Kritik und Feedback zu verfassen.
5. Feedback und Kritik sollen konstruktiv, sachlich, und freundlich formuliert sein.
6. Alle Autoren sollen Feedback und Kritik begrüßen und annehmen.
   • Autoren sind jedoch nicht verpflichtet, jedes Feedback anzunehmen, etwa wenn es ihr Konzept sprengen würde. Gleichzeitig sind Freigeber nicht verpflichtet, Artikel freizugeben, wenn der Autor ihrer Meinung nach wichtige Punkte nicht umsetzen möchte. Dafür haben wir mehrere Freigeber.
   • Es kann mitunter sehr lange dauern, bis ein Artikel freigegeben ist, und sehr viel Feedback kommen. Das ist ein normaler Prozess.
   • Wenn es etwas länger dauert bis du Feedback bekommst, kannst du alle drei Tage im Chat nach weiterem Feedback fragen.
   • Es kann sein, dass sich trotz Feedback nicht alle Feedbackgeber einig sind. Ein Artikel muss allerdings nicht jedem zusagen.
   • Feedback kann jede beliebige Form haben, und sowohl im Forum, im Chat, aber auch im Voicechat erfolgen. Alle Methoden haben Vor- und Nachteile.

Freigaben

1. Alle Artikel müssen vor dem Veröffentlichen freigegeben werden.
2. Nicht freigegebene Artikel, die im Hauptwiki gepostet werden, werden gelöscht und der Autor für eine Woche gebannt.
3. Freigabeberechtigt sind: Administratoren und Mitglieder des Freigabeteams.
   • Alle Freigaben zählen gleich, egal, von wem sie kommen, es sei denn eine andere Regel verlangt ausdrücklich administrative Freigabe.
4. Wenn Artikel Feedback bekommen haben, und es erscheint, als wäre kein weiteres Feedback zu erwarten, sollen die Freigabeberechtigten den Artikel hinsichtlich Freigabe prüfen.
   • Die Freigaben sollten sich nach Möglichkeit anhand sachlicher Punkte orientieren, nämlich: Rechtschreibung, Ausdruck, rechtliche Unbedenklichkeit, keine der Community abträgliche Inhalte, funktionales Konzept und funktionales Narrativ.
5. Zwar sollen Freigeber sich an sachlichen Punkten orientieren, ihre eigene Meinung dürfen sie jedoch auch einfließen lassen.
6. Freigeber sollen sich mit ihrer Freigabe nicht zurückhalten, nur weil ein anderer Freigeber noch nicht zufrieden ist.
7. Administratoren haben ein Vetorecht, wenn ein Artikel sich als rechtlich oder ethisch bedenklich erweist.
8. Die „Veteranenregel” (dass User mit 3 Artikeln über 15+ insgesamt nach einer Woche ohne Freigabe veröffentlichen dürfen) ist bis auf weiteres ausgesetzt.
   • Sie tritt automatisch und für alle Arten von Artikeln wieder in Kraft, wenn nur noch zwei (2) Freigabeberechtigte über einen Zeitraum von drei (3) Wochen aktiv sind, und außer Kraft, wenn wieder mehr Freigabeberechtigte aktiv sind.
9. Die artikelspezifischen Freigaberegelungen sind wie folgt:

Art des Artikels	Freigabebedingungen
SCPs	2 Freigaben oder fünf User die dem Werk zustimmen + 1 Freigabe (Anmerkung: Aufgrund der gegenwärtigen Lage reicht auch eine Freigabe durch einen Admin.)
Geschichten	1 Freigabe durch einen Freigabeberechtigten oder 7 Tage im Feedbackforum nach dem letzten Feedback
GoI-Formate	1 Freigabe
Essays	1 Freigabe
Interessengruppen	1 Freigabe des Konzepts, dann Erstellung einer Portalseite. Nach fünfmaliger (5x) Verwendung in Artikeln mehrerer Autoren administrativer Konsens über offizielle Anerkennung.
Kanons	1 Freigabe des Konzepts, dann Erstellung einer Portalseite. Nach fünfmaliger (5x) Verwendung in Artikeln mehrerer Autoren administrativer Konsens über offizielle Anerkennung.
Eintrag in Standortliste	Allgemeiner Konsens, 1 Adminfreigabe
Eintrag in MTF-Liste	Allgemeiner Konsens, 1 Adminfreigabe
Standortdossier	Freigabeberechtigten Konsens
Eintrag in Charakterliste	Freigabeberechtigten Konsens
Autorenseiten	Keine Freigabe, mindestens ein Artikel oder Übersetzung verfasst, oder Ersteller von Artworks, Videos, usw.
Artwork-Hubs	Keine Freigabe
Components	1 sachkundiger Admin
Themes, Scripts	1 sachkundiger Admin
Übersetzungen	Keine Freigabe (1 Freigabe bei Freigabeverpflichtung)
Sonstige	1 Freigabe

Nach der Veröffentlichung

1. Alle Artikel sind mit Tags zu versehen.
   • Beachte zwingend die Tagregeln weiter unten, sowie die vorgeschriebenen Tags in den Medienlizenzierungs- und Coderegeln.
2. Solange der Autor nichts anderes angibt, setzt nur dieser Attribut-Tags; manche nutzen das als Stilmittel.
3. Alle Artikel sollen immer mit Elternseiten versehen werden, zwecks vereinfachter Navigation.
   • Bei Anhängen und Fragmenten ist immer der Hauptartikel als Elternseite zu setzen.
   • Bei anderen Artikeln sollte die Portalseite, in der sie primär aufgelistet sind, gesetzt werden.
   • Passt ein Artikel gleichermaßen zu mehreren Elternseiten, wie ein SCP das sehr auf einer Interessengruppe beruht, ist die Primäre Elternseite zu setzen (um der technisch korrekten Struktur), und es können mehrere Fake-Elternseitenlinks platziert werden.

Übersetzungen

Maschinell erstellte Übersetzungen sind nicht erlaubt und werden gelöscht!

Inhalt
Maschinelle Übersetzungen
Vorbereitung
Übersetzungsregeln
Übersetzungen aus dem Deutschen
Grundbegriffe

Denn maschinelle Übersetzungen mit Google o. ä. sind immer mangelhaft. Wie soll man stattdessen übersetzen?

• Absatz für Absatz lesen, verstehen, mit eigenen Worten auf Deutsch neu schreiben.
• Satz-für-Satz-Übersetzungen sollten vermieden werden, denn die haben oft eine unbefriedigende Grammatik, weil unbewusst auf Wort-für-Wort-Übersetzung zurückgegriffen wird.

Das dauert zwar länger und man bekommt nicht in kurzer Zeit zig SCPs übersetzt, aber das Ziel einer Seite wie dieser sollte nicht sein, möglichst viele SCPs zu übersetzen, sondern ausgewählte SCPs möglichst gut. Qualität vor Quantität.

Natürlich ist es erlaubt, Übersetzungsseiten als Hilfe heranzuziehen und wenn das Ergebnis inhaltlich korrekt ist, kann damit auch aus einer Sprache übersetzt werden, die ihr nicht selbst sprecht.

Vorbereitung

1. Vor einer Übersetzung ist zu prüfen, ob der Autor besondere Vorgaben zur Übersetzung und der Verwendung von Dateien gemacht hat; üblicherweise geschieht das auf der Diskussionsseite, manchmal auch im Quellcode. Diese sind einzuhalten!
   • Sollten die Vorgaben unsinnig erscheinen, kann sich in Ausnahmefällen, nach Absprache mit den Admins, die sich auch mit den Admins des fraglichen Wikis in Verbindung setzen können, darüber hinweggesetzt werden.
   • Verbote eines Autors, sein Werk zu übersetzen sind nicht mit der Lizenz kompatibel und als nichtig zu betrachten! Es sollte jedoch abgewogen werden, ob man einem solchen Individuum eine Plattform bieten will.
2. Es ist in der Übersetzungsübersicht zu prüfen, ob bereits ein anderer Autor mit der Übersetzung beschäftigt ist und ob dieser Hilfe braucht/möchte.
   • Es wird gebeten, euch in die Übersetzungsübersicht einzutragen, wenn ihr an einer Übersetzung arbeitet.
   • Es gibt keine vorgegebene Reihenfolge. Ihr könnt übersetzen was ihr wollt.
   • Übersetzungen von internationalen Ablegern der Foundation sind ausdrücklich erwünscht!
   • Ist der Eintragende augenscheinlich länger nicht mit der fraglichen Übersetzung beschäftigt gewesen, kann er gebeten werden, die Übersetzung abzugeben.

Übersetzungsregeln

1. Wer viel übersetzt oder viel übersetzen möchte (ins Deutsche oder aus dem Deutschen), kann sich bei Dr Alice zwecks Aufnahme in das Übersetzerteam melden, um Übersetzungen besser zu koordinieren.
2. Es gibt bestimmte Begriffe, die immer gleich übersetzt werden, um einheitliche Maßstäbe beizubehalten. Diese sind im Übersetzungswörterbuch festgehalten. Das Glossar bietet einen weiteren Leitfaden, ist aber nicht verbindlich.
3. Alle Übersetzungen sind mit übersetzt und der Ursprungssprache (außer Englisch) zu taggen.
   • Bitte alle Tags des Originals übersetzen, außer Wettbewerbstags und dergleichen
   • Siehe Tag Richtlinie, in der auch Übersetzungen aller gängigen Tags zu finden sind.
4. Fachbegriffe sollten direkt übersetzt werden.
5. Es sollte versucht werden, die Ausdrucksweise und den Tonfall des Originals nachzuahmen. Sie kann vom Originalautor als Stilmittel verwendet worden sein und gehört natürlich auch in die Übersetzung.
6. Mit dem Credit Modul und/oder in der Diskussionsseite einer Übersetzung ist auf das Original zu verlinken, der/die Originalautor/en und Rechteinhaber der Dateien und ggf. Copyrightinformationen zu nennen.
   • In dieser Liste finden sich alle relevanten Autoren zu jedem Artikel. Sollte ein Artikel nicht aufgeführt sein, nennt bitte den ersten in der Historie des Artikels.
   • Derartige Links und Informationen haben jedoch nichts in der Übersetzung bzw. dem Dokument selbst zu suchen.
   • Das Pаsswоrt für die Sаndbоx ist Goldfischglas (ohne Leerzeichen dahinter!).
7. Manche Medien unterliegen strengen Vorgaben oder dürfen nicht außerhalb des Originalwikis verwendet werden. Solche Regeln sind unbedingt einzuhalten.
8. Medien in Übersetzungen sollten aus dem Originalwiki verlinkt werden, anstatt sie bei uns hochzuladen, sofern sich daraus keine Datenschutzrechtlichen Probleme durch externe Plattformen ergeben.
9. Übersetzer können in Einzelfällen verpflichtet werden, Übersetzungen freigeben zu lassen. Hierzu gelten die Regeln in der Sektion „Freigabe“ im Abschnitt „Neue Artikel“.
10. Ein Übersetzer, der eine Übersetzung nicht fertiggestellt bekommt, kann sie in eine Sandbox speichern und in der Übersetzungsübersicht als abgebrochen markieren, und den Link zur Sandbox bereitstellen, damit jemand anders die Übersetzung wiederaufnehmen kann.
11. Die Elternseite einer Übersetzung sowie Anhänge sind so zu setzen wie im Original, sofern die Elternseiten existieren, und keine absonderlichen Artikel dafür ausgewählt wurden.
12. Es gelten auch für Übersetzungen die Einschränkungen aus der Sektion Coderegeln, insbesondere in Bezug auf Themes und CSS. Hier kann gerne mit Dr_Grom Rücksprache gehalten werden. Regelinkonforme Themes sind zu entfernen.

Übersetzungen aus dem Deutschen

Zum Beispiel auf Englisch im Internationalen Übersetzungsarchiv oder für andere Ableger.

1. Autoren haben ein Vorrecht ihre Artikel in andere Sprachen zu übersetzen.
   • Wer einen fremden Artikel zu übersetzen wünscht, muss sich mit dem Autor absprechen.
   • Artikel inaktiver Autoren können ohne Rücksprache übersetzt werden.
2. Es gelten die Regeln des Ziel-Wikis bezüglich Übersetzungen
3. Es sind in jedem Fall in den Credits mindestens alle Urheber, Übersetzer, Medienersteller, sowie alle Quellen zu nennen, unabhängig davon was im Ziel-Wiki gefordert wird.

Grundbegriffe

Dies sind Begriffe, die immer wieder vorkommen. Die Verwendung dieser Übersetzungen ist verbindlich.

• Item # = Objekt-Nr.
• Object class = Klassifizierung
• Special Containment Procedures = Sicherheitsmaßnahmen. Der Wortwitz geht mit der Übersetzung ohnehin verloren.
• Description = Beschreibung
• Addendum = Anhang oder Nachtrag, je nachdem was eher zutrifft.
• Safe = Sicher
• Neutralized = Neutralisiert
• [Data expunged] = [DATEN GELÖSCHT]
• [Redacted] = [ZENSIERT]
• Site = Standort
• Containment = Eindämmung – sollte falls möglich durch passenden Ersatz wie („SCP-173 in seiner Zelle“) ersetzt werden
• Containment Chamber = Isolierzelle
• Amnestic = Amnesikum (Mehrzahl: Amnesika; Verb: amnesizieren)
• Caucasian = Hellhäutig oder europäischer Typ. (Der Begriff des Kaukasoiden bzw. Europiden entstammt der Drei-Großrassentheorie des 18ten Jahrhunderts bzw. des Dritten Reiches und wird im Deutschen selbst in der Anthropologie seit den 90ern nicht mehr verwendet. Heute ist ein Kaukasier ein Bewohner des Kaukasus.)

Eigennamen und foundationweit verwendete Begriffe werden meist nicht übersetzt. Das sind zum Beispiel: „SCP Foundation“, „Secure. Contain. Protect“, und „█“.

(Medien-) Lizenzregeln

Inhalt
Allgemeine Lizenzregeln
Medienlizenzregeln
Was lizenziert werden muss
Lizenzinformationen
Ort der Lizenzangabe
Selbsterstellte Medien
Besonderheiten bei Code
Medien und die DSGVO
Lizenz-Tags
Quellen für Medien

Allgemeine Lizenzregeln

1. Es gibt für die gesamte Sektion „(Medien-) Lizenzregeln“ keine Ausnahmen.
2. Jeder Artikel und jede Datei ist Eigentum des Urhebers. Eine Bearbeitung durch Dritte ist allerdings zulässig, wenn der Urheber nicht ausdrücklich widersprochen hat und für Kritik und Hinweise erreichbar ist.
   • Das gilt auch für Übersetzungen.
   • Zwar mag die Lizenz eine Bearbeitung erlauben, aus Gründen der Höflichkeit ist dies mit dem Autor abzusprechen, siehe Allgemeine Artikelregeln Absatz 2.
3. Alle Artikel und Medien, die direkt mit der SCP Foundation und ihrem Universum zu tun haben, unterliegen automatisch und unveränderlich der Creative Commons Attribution-ShareAlike 3.0 Lizenz.
   • Jeder kann seinen Artikel unter einer anderen Lizenz veröffentlichen, sofern diese zur Natur der Webseite passt, jedoch nicht, wenn sie in irgendeiner Form mit der SCP Foundation oder einer anderen Interessengruppe in Verbindung steht. Alle Artikel, die auf diesem Hintergrund basieren, sind Derivate im Sinne der Lizenz und daher CC BY-SA 3.0. Andere als CC-Lizenzen sind mit dem Team zu besprechen und die Artikel entsprechend zu kennzeichnen.
4. Alle Artikel die der CC BY-SA 3.0 Lizenz unterliegen, unterliegen dieser gemäß den Lizenzbestimmungen in ihrer Gänze, das heißt inklusive aller Medien. Medien müssen also unter CC BY-SA 3.0 oder einer kompatiblen Lizenz vorliegen, um verwendet werden zu dürfen, weil bei der Veröffentlichung als Teil eines CC BY-SA 3.0 unterliegenden Artikels diese unter dieser Lizenz wiederveröffentlicht werden, und in dem vorliegenden Werk ihre Lizenz angepasst wird.
   • Medienersteller aufgepasst! Wenn ihr eure Werke für einen SCP-Artikel erstellt oder bereitstellt, wird dieser zwangsweise unter CC BY-SA 3.0 veröffentlicht. Erscheinen darin der Lizenz unterliegende Elemente wie das SCP-Logo, wird es durch den SCP-Bezug es nicht mehr möglich, das Werk anderswo unter einer anderen Lizenz zu veröffentlichen!
5. Wenn ihr einen kopierten Artikel oder ein Medium einfügt, das eine andere Lizenz als dieses Wiki (CC BY-SA 3.0) hat, müsst ihr diese beachten und nennen. Siehe Medienlizenzierungsregeln.
6. Jeder User, der hier etwas veröffentlicht, ist dafür verantwortlich, die korrekte Lizenz anzugeben, und die Lizenzbedingungen korrekt zu erfüllen. Die Administratoren übernehmen ausdrücklich keine Verantwortung dafür. Fehlerhafte Lizenzangaben werden bei Erkennen umgehend korrigiert, beziehungsweise Werke, deren Nutzung nicht statthaft ist, werden gelöscht und den Veröffentlichern wird eine Disziplinarmaßnahme zuteil.
7. Wir reden hier nicht über Verhaltensregeln, sondern über Regeln zur Umsetzung von Gesetzen. Da hier Geldbußen im Raum stehen, fahren wir eine Null-Toleranz-Politik. Wer keine Lizenzangaben vorweisen kann, bekommt eine Frist, diese nachzureichen. Nach Ablauf dieser wird das Medium gelöscht. Bei Wiederholung droht ein Bann.

Medienlizenzregeln

Eine Medienlizenz sind Nutzungsbedingungen, keine Eigentumsbedingungen. Generell verbleibt das Urheberrecht immer beim Urheber. Mit einer Lizenz erlaubt der Urheber die Benutzung, wenn bestimmte Regeln eingehalten werden. Keine Lizenz = Kein Nutzungsrecht.
Das ist gesetzlich geregelt, und im Abmahnparadies Deutschland kann man sich da durchaus teuren Ärger einhandeln. Des Weiteren ist es nur fair, sich an die Lizenzbedingungen zu halten. Ihr veröffentlicht eure Artikel ja auch zu den Bedingungen der CC BY-SA 3.0 Lizenz, und wollt gewiss nicht, dass die einfach irgendwie anders genutzt werden.

Da früher hier nicht so sehr auf die Lizenzen geachtet wurde, sind einige Medien unter inkompatiblen Lizenzen veröffentlicht. Diese sind nach und nach zu korrigieren. Jeder ist dazu aufgerufen dabei mitzuhelfen, siehe Lizenzraid.

Was lizenziert werden muss

1. Alles.
2. Im Detail (ohne Gewähr auf Vollständigkeit): Artikel (SCP-Artikel sind zwangsläufig CC BY-SA 3.0, daher genügt die Nennung des Urhebers), Bilder, Audiodateien, Videos, CSS-Code, HTML-Code, Scripts, Schriftarten, u. a.

Dabei ist es egal, ob ihr diese Medien hier im Wiki hochladet, woanders hochgeladen habt oder sie gefunden und nur verlinkt habt.

Erforderliche Lizenzinformationen

1. Quelle (Link)
   • Bei Übersetzungen nicht das Bild im Originalwiki, sondern die tatsächliche Quelle.
2. Urheber (Real- oder Nickname und ggf. Link zum Profil)
   • Manchmal ist bei der Quelle kein Urheber angegeben oder dessen Account gelöscht. In dem Fall kann und muss kein Urheber angegeben werden, bzw. dieser ist als „anonym“ oder „unbekannt“ anzugeben.
3. Lizenz
   • Hier ist die Ursprungslizenz gemeint. Alles im Wiki mit SCP-Bezug unterliegt hier ausnahmslos CC BY-SA 3.0!
   • Es kann sein, dass ihr Medien verwendet, bei denen all dies von der Ursprungslizenz her gar nicht angegeben werden muss, zum Beispiel bei gemeinfreien Medien. Allerdings werden in diesem Wiki der Übersicht halber immer diese Informationen gefordert, sofern bekannt.
   • Manche Dateien, insbesondere auf Wikipedia, sind unter mehreren Lizenzen veröffentlicht. Das heißt üblicherweise, dass ihr euch eine aussuchen dürft. Es wird bevorzugt, alle Ursprungslizenzen zu nennen.
   • Die angegebene Lizenz ist nicht die Lizenz unter der ihr das Medium hier wiederveröffentlicht, das geschieht immer unter CC BY-SA 3.0. Ihr gebt die Ursprungslizenz an. Das dient der besseren Übersicht, Transparenz und Nachprüfbarkeit.
4. Optional: Zusatzinformationen, etwa wenn der Urheber das fordert oder erbittet.

Ort der Lizenzangabe

• Creditmodul
• Kommentare
• Zusätzlich sind DE-SCPs in der SCP-DE Urheberliste aufzuführen.
• Alle drei (empfohlen).

Zwar ist es möglich, Lizenzinformationen direkt in den Artikel zu packen, wie bei SCP-173 oder darin zu verstecken, wie bei SCP-111. Dies ist jedoch unerwünscht und nur, wenn es sich als nötig erweist, zu praktizieren. Diese Medien wie bei SCP-173 sind ein Sonderfall und eigentlich nicht mit der Lizenz kompatibel, da sie nicht unter CC BY-SA 3.0 sondern einem exklusiven Nutzungsrecht abgebildet werden. Hier befindet man sich in einer rechtlichen Grauzone und ist bei Originalartikeln dieses Wikis nicht gestattet.

Selbsterstellte Medien

Medien, die ihr selbst erstellt habt, und die ihr unter CC BY-SA 3.0 (also der Lizenz des Wikis) veröffentlichen wollt, braucht ihr nicht weiter zu kennzeichnen, außer, dass sie von euch sind (wenngleich klare Angaben besser sind). Bedenkt allerdings, dass die Veröffentlichung von selbst erstellten Medien in diesem Wiki automatisch und unabänderlich unter CC BY-SA 3.0 geschieht. An anderer Stelle könnt ihr sie - als Urbeber - unter jeder anderen Lizenz ebenfalls veröffentlichen, auch unter welchen die mit der CC BY-SA 3.0 Lizenz nicht kompatibel sind, außer sie enthalten SCP-Bezug oder wurden speziell für einen Artikel erstellt. Von Wiederveröffentlichungen unter andere Lizenz durch den Urheberrechtsinhaber an anderer Stelle bleibt die Lizenz hier unberührt.

Eine Änderung der Lizenz ist spätestens dann nicht mehr möglich, wenn die Datei an anderer Stelle wiederveröffentlicht wurde, bzw. dann liegt sie in zwei Lizenzen vor, weil die Lizenz für die wiederveröffentlichte Datei unverändert bleibt. Da das nur zu Theater führt, überlegt euch bevor ihr ein Medium veröffentlicht, unter welcher Lizenz ihr das tun wollt. Dafür könnt ihr die CC-Lizenz Auswahlhilfe benutzen. Bedenkt dabei aber, dass Medien unter mit CC BY-SA 3.0 inkompatibler Lizenz nicht in SCP-Artikeln veröffentlicht werden dürfen, und Werke mit SCP-Bezug immer automatisch CC BY-SA 3.0 unterliegen.

Dies ist nicht mit der Veröffentlichung fremder Werke ohne Lizenzangabe zu verwechseln. Wenn sie so ohne Lizenzangabe im Wiki stehen, mögen sie zunächst als unter CC BY-SA 3.0 erscheinen, sind aber falsch oder unzureichend lizenziert, was einen Gesetzes- und Regelverstoß darstellt (die meisten Lizenzen sind durch internationale Verträge rechtswirksam und können weltweit eingeklagt werden). Des Weiteren können damit Urheberrechte verletzt worden sein, was überaus teuer werden kann, und es passiert durchaus, dass Leute dafür belangt werden.

Besonderheiten bei Code

CSS-Styles, HTML-Code und Scripts sind wie alles andere auch durch das Urheberrecht geschützt und bedürfen einer Lizenz. Da sie hier zumeist in Artikelform vorliegen, bzw. direkt in Artikeln vorliegen, wird, wenn sonst nichts dabeisteht, von einer Veröffentlichung unter CC BY-SA 3.0 ausgegangen. Bitte packt bei Themes, längeren Scripts und CSS die Urheber- und Lizenzinfos in einen Kommentar am Anfang des Codes.

Code, der nicht von euch selber stammt, ist wie alle anderen Medien auch zu lizenzieren. Mittels Credit-Modul oder in den Kommentaren.

Externer Code ist wie externe Bilder zu behandeln: Mit vollen Lizenzangaben.

Medien und DSGVO-Hinweise

Manche Medien werden auf Seiten gehostet, die selbst Nutzerdaten sammeln, wenn Medien von ihnen aufgerufen werden, insbesondere Schriftarten, z. B. Google Fonts. Ebenso können Scripts und eingebettete Dienste Daten sammeln. In dem Fall seid ihr als Artikelautoren verpflichtet, eine DSGVO-Erklärung abzugeben! Und zwar zwingend im Creditmodul, und in den Kommentaren.

Die allgemeine Datenschutzerklärung dieses Wikis enthält bereits eine Erklärung zur Nutzung von GitHub und Google Fonts, eine weitere Erklärung hierzu ist nicht nötig.

Lizenz-Tags

Alle Seiten mit Medien sind mit einem oder mehreren dieser Tags zu versehen:

• _bild: Der Artikel enthält ein Medium. Wird immer für Artikel mit Medien verwendet.
• _cc: Medien in dem Artikel liegen in CC BY-SA 3.0 oder einer kompatiblen Lizenz vor. Kompatible Lizenzen sind zum Beispiel:
  • Gemeinfrei/Public Domain
  • CC0 1.0
  • CC BY (Alle Versionen)
  • CC BY-SA 4.0 (technisch gesehen steht der Gesamtartikel unter 4.0 und nur der Text wird unter 3.0 eingebettet)
  • Open Audio License
• _ncc: Medien liegen in einer nicht mit der CC BY-SA 3.0 kompatiblen Lizenz vor. Sie sind zu ersetzen oder zu entfernen. Nicht-kompatible Lizenzen sind zum Beispiel:
  • CC BY-NC
  • CC BY-SA-NC
  • CC BY-ND
  • CC BY-NC-ND
  • Pixabay-Lizenz
  • Pexels-Lizenz
  • FreeImages.com Inhaltslizenz
  • © Urheberrechtlich geschützt mit Nutzungsrechten
• _occ: Es liegen keine Lizenzinformationen vor; es wird nach der Quelle oder einer Alternative gesucht.
  • Nur für Übersetzungen
  • Nur, wenn im Originalwiki auch konsequent nach der Quelle oder einer Alternative gesucht wird. Ansonsten muss das Medium gelöscht werden. Auch aus dem Dateiverzeichnis.
• Ohne _bild: Der Artikel enthält kein Medium oder wurde noch nicht geprüft.

_cc, _ncc und _occ sind bei Bedarf zu kombinieren, jedoch immer in Verbindung mit _bild.

Fehlerhaft gesetzte Tags dürfen (und sollen) von jedem korrigiert werden. Neue Artikel mit Medien müssen direkt korrekt getaggt und lizenziert werden. Aufgrund des hohen Bestandes an fehlerhaft lizensierter Medien kann die Umstellung noch andauern. Dies stellt keine Präzedenz für neue Artikel dar.

Quellen für Medien

Dies sind Webseiten auf denen – bis auf vielleicht einige Ausnahmen – Medien in geeigneten Lizenzen gefunden werden können. Vorschläge für weitere Einträge sind hoch willkommen.

Bilder:

• Wikimedia Commons – Weitgehend CC BY-SA 3.0 bis gemeinfrei.
• Flickr – Oft kompatible CC-Lizenz

Schriftarten:

• Google Fonts – Meist in der Open Font License

Coderegeln (CSS und Scripts)

Diese Regeln betreffen CSS, JavaScript, HTML, PHP und alle anderen Scripts und externe Code-Referenzen. Mit „Code“ ist hier alles außer Wikidot-Syntax gemeint.

Inhalt
Grundregeln
Code in Artikeln
Verbote
Funktionalität
Quellcode
Integration
Lizensierung
Themes
Freigabe
Kompatibilität
Aufgeblähter Code
Barrierefreiheit
Referenzen & Hotlinking
Code-Artikel

Grundregeln

Themes und CSS in Artikeln

1. Die Verwendung von CSS und Themes, welche das Sigma-9-Theme sichtbar verändern, ist nicht gestattet, außer unter folgenden Ausnahmen:
   • Es ergibt in-universe Sinn (zum Beispiel bei Kanon-Seiten, GOI-Formaten, Witz-Artikeln oder Contests und Events unter einem bestimmten Thema).
   • Es handelt sich um kleine, nicht oder kaum sichtbare Bugfixes oder Verbesserungen (bitte mit Dr_Grom absprechen).
   • Es handelt sich um eine Autoren- oder Artworkseite.
   • Es handelt sich um Elemente innerhalb des Artikels, also der Inhalt von <div id="page-content">, <div id="page-title"> und <div id="breadcrumbs">. Z.B. ein anderes Format für die graue Box. Diese sind als Stilmittel zu betrachten. Dabei zu fancy zu werden ist jedoch nicht empfohlen.
2. Diese Regel gilt auch für Übersetzungen, aus welchen unzulässige Themes zu entfernen sind.
3. Seiten, welche (regelkonform) ein Theme verwenden, sind mit _theme zu taggen, damit das Theme überprüft und gegebenenfalls Bugs korrigiert werden können.
4. Neue Themes bedürfen einer Freigabe durch einen sachkundigen Administrator.

Verbote

1. Die Verwendung von Cookies ist verboten.
2. Schadcode ebenfalls.
3. Session-Variablen und andere über die aktuelle Sitzung auf einer Seite, über das schließen aller Tabs mit der Seite hinausgehend zwischengespeicherten Daten, sind nur nach Prüfung durch einen sachkundigen Admin zulässig.
4. Verschlüsselter Code ist nicht gestattet. Der Quellcode muss menschenlesbar sein.
5. Es darf keine Datenerfassung irgendeiner Art stattfinden.
6. Es darf kein Code ausgeführt werden, der nicht ausdrücklich der Präsentation des Artikels dient.
7. Es dürfen keine Navigationselemente oder das Bewertungsmodul verborgen oder unkenntlich gemacht werden.
   • Ausnahme: Bei Verwendung von Themes die nicht mit dem Dark-Mode kompatibel sind, darf der Dark-Mode-Button ausgeblendet werden.
8. Es dürfen keine stark blinkenden, sich bewegenden, oder sonstige für Epileptiker gefährlichen Elemente verwendet werden.

Funktionalität

1. Generell muss jeder Code, der das Gesamtbild verändert, in-universe begründbar sein. Dies gilt insbesondere für Themes.
   • Artikelelemente anders zu gestalten ist erlaubt und wird als Stilmittel betrachtet.
   • Witz-Artikel, Autoren- und Artworkseiten sind davon ausgenommen.
2. Die Seite muss so weit wie möglich barrierefrei sein, sprich für Personen mit Sehschwäche oder Farbenblindheit nicht unzuträglich, und für Screen Reader nicht unnötig schwer zu handhaben sein.
3. Code, der ohne das explizite Zutun des Users (z.B. das klicken eines „Play“ Buttons) Ton oder Video abspielt, bedarf administrativer Genehmigung.
4. Code, der Jumpscares einbaut, bedarf administrativer Genehmigung.
5. Code muss mit den gängigen modernen Browsern kompatibel sein.
   • Die Seite darf bei fehlender Unterstützung des Codes nicht unlesbar werden.
   • Es wird eine Kompatibilisierung mit Präfixes empfohlen, zum Beispiel mit Autoprefixer bei CSS.
   • Code darf die Seite auf sehr alten Browsern nicht unbrauchbar machen. Ist keine ausführliche Rückwärtskompatibilität integriert, ist der Code z.B. mit @supports auf den Code voll unterstützende Browser zu beschränken.
6. Code hat auf Desktop- wie auch Mobilgeräten gut zu funktionieren, oder mittels @media oder @supports auf eines beschränkt zu werden.
7. Code der Elemente außerhalb der <div id="page-content">, <div id="page-title"> oder <div id="breadcrumbs"> beeinflusst (also insbesondere Themes), bedarf einer Freigabe durch einen sachkundigen Administrator.

Quellcode

1. Code, dessen Quellcode nicht jederzeit vom User eingesehen werden kann (zum Beispiel über die Entwickleroberfläche des Browsers oder den Quellcode im Artikel oder einem Component-Artikel), muss zwecks administrativer Freigabe offengelegt werden.
2. Minifizierter Code und Code in hochgeladenen Dateien ist erlaubt und empfohlen.
   • Es wird empfohlen, eine kommentierte nicht minifizierte Version in dem dazugehörigen Artikel vorzustellen.
   • Minifizierter Code in hochgeladen Dateien muss einen Kommentar mit mindestens Urheber und Lizenz enthalten.
3. Verschlüsselter Code ist jedoch verboten.
4. Externe Quellen sind zu vermeiden, und Daten nach Möglichkeit in dem Artikel oder einem Component-Artikel hochzuladen.
   • Quellen auf anderen mit der SCP-Foundation assoziierten Wikidot-Seiten sind statthaft, um Redundanz zu vermeiden.
   • Werden externe Quellen verwendet, sind diese zu nennen und es ist eine Datenschutzerklärung abzugeben. Für GitHub und Google Fonts ist diese bereits in der des Wikis enthalten.
   • Externe Quellen müssen eine Lizenz aufweisen, die eine Verwendung hier erlaubt.
5. Code sollte auf eine schnelle Ausführung optimiert sein. Redundanz ist zu vermeiden.
6. Code ist ausführlich auf Bugfreiheit zu testen. Bugs sind schnellst möglich nach bekanntwerden zu beheben.
7. Es sollte ein Versionslogbuch geführt werden.
8. Der Artikel darf nicht unlesbar werden, wenn der User einen Scriptblocker verwendet.

Integration

1. Code darf sowohl in den Artikel eingebettet, als auch in einem inkludierbaren Artikel oder externen Plattformen wie GitHub veröffentlicht werden.
   • Code, der auch auf andere Artikel anwendbar ist, sollte in einen separaten Artikel gespeichert werden.
   • Themes sind stets als separater Artikel zu veröffentlichen.
2. Artikel auf die ein Theme angewandt wurde, sind mit _theme zu taggen.
3. Inkludierbare Artikel in denen der Code separat veröffentlicht wird, sind in der Kategorie component: zu speichern.
4. Themes sind in der Kategorie theme: zu speichern (alte Themes werden nach und nach in diese Kategorie verschoben).
5. Themes sind mit theme zu taggen, Scripts mit script; außerdem beide mit component. Zu einem Theme gehörige Scripts und Code dürfen im Theme-Artikel gespeichert werden.
6. Code, insbesondere Themes, sind über die [[include]] Methode bereitzustellen, nicht über @import (alte Themes werden mit der Zeit auf diese Methode upgedatet). Siehe Abschnitt „Code-Artikel".

Lizensierung

• Jeder Quellcode, der hier im Wiki gepostet oder hochgeladen wird, muss unter CC BY-SA 3.0 oder einer kompatiblen Lizenz veröffentlicht werden.
• Eingebetteter Code, der über einfache Snippets hinausgeht, hat einen Kommentar mit Nennung der Urheber zu enthalten.
• Externe Quellen müssen eine Lizenz aufweisen, die eine Verwendung hier erlaubt.
• Minifizierter Code in hochgeladen Dateien muss einen Kommentar mit mindestens Urheber und Lizenz enthalten.

Themes

Freigabe

Wie alle anderen Artikel auch, sollten Themes in einer Sandbox erstellt werden. Erstelle zum Testen eine Demo-Seite in der Kategorie menuetest: in der Sandbox, dazu kannst du die Testseite kopieren und dein Theme einfügen. Die Kategorie simuliert die Menüs und Funktionalität des Hauptwikis. Kontaktiere die Admins (vorzugsweise auf Discord), um dein Theme auf Fehlerfreiheit zu prüfen, und zur allgemeinen Begutachtung zu stellen. Du kannst auch einen Forenthread für Feedback für dein Theme erstellen.

Allgemein muss jeder Code, der einer Genehmigung bedarf, sowohl „in Action“ betrachtet, als auch der Quellcode eingesehen werden.

Kompatibilität

Beachte, dass das SCP-DE Wiki das Common-Theme verwendet, und CSS-Variablen unterstützt, was es wesentlich einfacher macht, Themes zu erstellen. Das Common-Theme ist hier dokumentiert. Allerdings unterstützen ältere Browser keine Variablen. Damit dein Theme nicht falsch dargestellt wird, wenn du nur Variablen verwendest, packe deinen gesamten Code in die Regel @supports (--foo: green) { ... }. Damit wird dein Code nur dargestellt, wenn der Browser Variablen unterstützt, andernfalls wird das Standardtheme verwendet. Du kannst auch andere Auswahlkriterien verwenden, wenn du andere Dinge verwendest, die nicht von allen Browsern unterstützt werden. Du kannst das umgehen, indem du Fallback-Regeln verwendest.

Generell ist es stets sinnvoll, deinen CSS-Code auf Kompatibilität zu prüfen, und kompatiblen Code zu verwenden (manche Browser unterstützen Funktionen, vor der Einführung, eine Weile nur testweise, wenn ein Präfix vorangestellt wird, wie -webkit-. Das Common-Theme ist mit Autoprefixer geprüft.

Grundsätzlich darfst du Themes auf Basis des Black Highlighter Theme (ehemals „nuTheme“) erstellen, allerdings kommt das nicht bei jedem gut an. Wenn du das BHL verwenden willst, nutze dieses Kompatibilitätsfix und binde es direkt in deinem Code-Artikel ein.

Aufgeblähter Code

Verwende keinen Code, den du nicht brauchst. Vermeide es insbesondere, einfach Code aus dem Common-Theme zu kopieren, und dann nur eine Regel zu ändern. Früher wurde gern das ganze Theme kopiert und nur einige Änderungen vorgenommen. Das ist nicht nötig und nicht zugelassen.

Achte darauf, keinen unnötig redundanten Code zu verwenden, oder Code der keine Wirkung hat. Verwende !important nur, falls es nicht anders geht. Stattdessen ist es stets zu bevorzugen, die Priorität deines Codes durch Hinzufügen höherwertiger Selektoren zu erhöhen. Falls dir das alles nichts sagt, frag lieber nach bevor du !important verwendest :)

Um die Ladezeit noch um ein Stück zu optimieren, kannst du deinen Code minifizieren, also alle Kommentare, Zeilenumbrüche, Leerzeichen, usw. löschen. Dafür gibt es auch massig Tools im Internet. Es wird empfohlen, minifizierten Code in eine Datei zu speichern und hochzuladen, das erspart es Wikidot, den Code bereitzustellen, wenn der User ihn abruft. Das Common-Theme wird mit diesem Tool minifiziert.

Barrierefreiheit

Themes müssen für möglichst viele Nutzer verwendbar sein:

• Für Farbenblinde sollten zum Beispiel ungünstige Kombinationen und dergleichen vermieden werden, dazu gibt es hier ein Tool zum auswählen von Farbkombinationen.
• Es sollten nach Möglichkeit keine unsichtbaren Elemente, verwendet werden, da Screen Reader diese unter Umständen trotzdem vorlesen.
• Schrift muss groß genug und gut lesbar sein. Außerdem muss der Kontrast zum Hintergrund ausreichend sein.

Es gibt diverse Browsererweiterungen, die die Barrierefreiheit prüfen. Wikidot ist was das angeht ohnehin ein Minenfeld, gerade für Screen Reader, das sollte also nicht vernachlässigt werden.

Externe Referenzen und Hotlinking

Externe Referenzen sind alle Dateien und Code, der von außerhalb des Wikis importiert wird. Meist betrifft das Bilder und Schriftarten. Hotlinking ist, externe Referenzen (meist Bilder von einer externen Seite) einzubinden. Das erzeugt dort aber zusätzlichen Traffic, außerdem verzögert es das Laden der Seite ein wenig, weil dein Browser Daten von einem weiteren Server anfragen muss.

Allgemein soll das vermieden werden. Referenzen haben auf Wikidot oder einer Seite, die ausdrücklich Hotlinking erlaubt, wie Bildhoster, oder Content Delivery Networks, vorzuliegen. Das Laden von Referenzen von Seiten, die dafür nicht ausdrücklich gedacht sind, ist nicht erlaubt.

Dennoch ist es stets vorzuziehen, Daten nur von einem mit der SCP-Community assoziierten Wikidot Wiki oder GitHub zu laden. Manchmal geht es nicht anders, weil PHP- oder Scriptvariablen in der URL übergeben werden müssen, um die richtige Datei zu laden, und diese nicht ohne funktioniert, das ist dann völlig in Ordnung, sofern nichts anderes dagegenspricht.

Schriftarten können von Google Fonts eingebunden werden, allerdings erlaubt hier in der Regel die Lizenz der Schriftart ein Hochladen auf anderen Seiten wie eben Wikidot oder GitHub. Wenn du dabei Hilfe brauchst, frag nur. Die Google-Verächter werden es dir danken.

Beachte, insbesondere was Bilder angeht, dass wir nicht unbegrenzt viel Speicherplatz zur Verfügung haben. Skaliere und komprimiere die entsprechend den Notwendigkeiten, dann bedarf es keines Bilderhosters. Die Maximalgröße für Bilder beträgt 1 MB!

Code-Artikel

Wenn du deinen Code in einem Component zur Verfügung stellst (für Themes ist das vorgeschrieben), veröffentliche dort folgende Informationen:

1. Beschreibung, wie der Code zu verwenden ist
2. Mögliche Variablen, Auswahl- und Anpassungsmöglichkeiten
3. Urheber und Lizenz
   • Externe Referenzen, deren Urheber und Lizenz
4. Gegebenenfalls Datenschutzerklärung
5. Der Code in nicht minifizierter, kommentierter Form zur Veranschaulichung, oder ein Link zu ebendiesem.

Beachte die vorgeschriebenen Tags theme, script und component. Ohne funktioniert der folgende Code nicht richtig.

Verwende diese Vorlage (hier am Beispiel eines Themes):

[[module CSS]]
@import url('http://scp-wiki-de.wdfiles.com/local--code/component:dein-theme/code/1');
[[/module]]

[[iftags +theme]]

[[>]]
[[module Rate]]
[[/>]]

Dies ist ein Beispiel von Jemandem.

Verwende folgenden Code, um das Theme in deinem Artikel anzuwenden:

[[div class="code"]]
@@[[include :scp-wiki-de:theme:dein-theme]]@@
[[/div]]

Dieses Theme ist für die Verwendung mit GoI-X1234 gedacht.

[[code type="css"]]
/* Hierhin kommt dein kommentierter, unminifizierter Code CSS. */
[[/code]]

[[/iftags]]

Passe die Adressen entsprechend an. „scp-wiki-de“ ist das Präfix des Wikis, „theme:dein-theme“ ist die Adresse deiner Seite, und „1“ ist die Nummer des Codeblocks in dem sich dein Theme befindet.

Du kannst in der @import Zeile einen Link zu einer minifizierten Datei verwenden. Auf deiner Seite soll stets der nicht-minifizierte, kommentierte Quellcode zu lesen sein. Du kannst allerdings den minifizierten Code ebenfalls dort posten statt in einer Datei.

Wenn dein Quellcode länger als eine Bildschirmseite ist, packe ihn in ein Collapsible.

Scripts können anderer Einfügemethoden bedürfen, und dürfen dementsprechend anders in den Artikel eingebaut werden. Der Inhalt einer solchen Seite soll dennoch dem gleichen Schema folgen.

Tagregeln

Inhalt
Was sind Tags?
Verwendung von Tags
Korrekturbedürfnislevel
Vorgeschriebene Tags
Charakter- und MTF-Tags

Was sind Tags?

Damit eine Seite besser zugeordnet werden kann, wird sie mit Tags, also Schlagwörtern versehen. Diese haben drei Funktionen:

• Sie lassen Rückschlüsse auf Art und Inhalt einer Seite zu, ohne den Inhalt zu kennen.
• Über die Tag-Wolke können leicht Seiten zum gleichen Thema gefunden werden.
• Sie kategorisieren eine Seite, was in Ermangelung von Kategorien, wie z.B. bei Wikipedia, erheblich zur Ordnung des Wikis beiträgt.
• Attribut-Tags können dem Autor als zusätzliches Stilmittel dienen.

Darum ist die Verwendung von Tags für alle Artikel verbindlich!

Um Tags für eine Seite zu setzen, unter dem Seitentext auf „Tags“ klicken, die jeweiligen Tags in die Zeile eintragen und bestätigen. Leerzeichen fungieren als Trenner zwischen zwei Tags und dürfen daher nicht als Leerzeichen verwendet werden. Tags werden automatisch klein geschrieben, egal wie sie eingegeben werden.

Die Tag-Wolke wird regelmäßig aufgeräumt, aber bitte macht uns nicht mehr Arbeit als nötig.

Verwendung von Tags

1. Dabei sind unten genannte vorgeschriebene Tags sowie optionale Attribut-Tags gemäß Tag-Wörterbuch zu verwenden.
2. Des Weiteren ist ein Korrekturbedürfnislevel zu setzen.
3. Artikel mit Medien sind entsprechend den Medienlizenzierungsregeln zu taggen.
4. Code-Artikel sind entsprechend den Code-Regeln zu taggen.
5. Solange der Autor nichts anderes angibt, setzt nur dieser Attribut-Tags; manche nutzen das als Stilmittel.
6. Jeder kann Fehler in Tags korrigieren, und fehlende erforderliche Tags ergänzen.

Korrekturbedürfnislevel

Das Korrekturbedürfnislevel gibt Aufschluss darüber, wie groß die Notwendigkeit von Rechtschreibprüfung, Korrektur und Prüfung der Übersetzungsqualität und -vollständigkeit ist, und wird durch Tags dargestellt:

• ⦿ = Vollständig übersetzt und überprüft.
• o = Ziemlich gut, muss nur noch ein letztes Mal geprüft werden.
• oo = Bedarf gewisser Aufmerksamkeit. Rechtschreibung und Grammatik sind weitgehend korrekt.
• ooo = Bedarf großer Aufmerksamkeit. Manche Sätze und Ausdrücke müssen womöglich umformuliert werden. Rechtschreibung und Grammatik können einiges an Korrektur bedürfen.
• oooo = Notfall! Teilweise Neuformulierung oder Neuübersetzung könnte nötig sein, während MTFs die Umgebung sichern. Auch für unvollständige Übersetzungen.
• anhänge-fehlen = Nicht alle Anhänge sind übersetzt worden.
• veraltet = Die Übersetzung ist nicht mehr aktuell und sollte erneuert werden.

Jeder, der eine Übersetzung korrigiert, entfernt ein „o“, der letzte Level kann jedoch nur von einem Korrekturbeauftragten entfernt werden! Das bedeutet, dass alle neuen Übersetzungen zumindest das Korrekturbedürfnislevel „o“ haben. Wird das letzte Level entfernt, wird es mit „⦿“ ersetzt.

Das Korrekturbedürfnislevel wird bei allen Artikeln außer Systemartikeln gesetzt, auch bei DE-SCPs. Das Eingangsminimum beträgt auch hier „o“. Artikel, die keiner Korrektur unterzogen werden sollen, erhalten den versteckten Tag „_o“ durch die Admins.

Wenn ein Autor oder Übersetzer seine Arbeit postet, schätzt er oder sie das Korrekturbedürfnis der Übersetzung, wobei das Minimum „o“ beträgt. Hier wird um eine realistische Einschätzung gebeten. Teammitglieder und Korrekturbeauftragte können den Level ändern, wenn sie ihn für unpassend halten. Jeder Nutzer kann den Level erhöhen, sollte der gegebene Level für unzureichend gehalten werden. Jeder Nutzer kann die Tags „anhänge-fehlen“ und „veraltet“ setzen.

Vorgeschriebene Tags

Artikel	Tags	Ausnahmen
Alle Artikel	Korrekturbedürfnislevel	Systemseiten
Übersetzungen	übersetzt	-
Übersetzungen	Ursprungssprache ausgeschrieben	Englisch
Übersetzungen	Alle original-Tags übersetzt	Wettbewerbs- und organisatorische Tags
Neuen DE-Seiten	deutsch	Systemseiten
SCPs	scp	-
SCPs	sicher / euclid / keter / thaumiel / usw.	Esoterische Klassen
Anhänge	anhang	-
Geschichten	geschichte	-
Essays, Aufsätze und Abhandlungen	abhandlung	-
Datenblätter	datenblatt	-
Poesie	poesie	-
GoI-Formate	goi-format	-
Portale	portalseite	-
Hintergründe	hintergrund	-
Vertonte Artikel	vertont	-
Artikel mit Medien	_bild	-
Lizenz-kompatibel	_cc	-
Nicht kompatibel	_ncc	-
Keine Lizenzangabe	_occ	-
Fragment-Artikel	fragment	-
Component-Artikel	component	-
Theme-Artikel	theme	-
Artikel mit Theme	_theme	-
Script-Artikel	script	-
Wettbewerbs-Artikel	_wettbewerb	-

Charakter- und MTF-Tags

• Charakter- und MTF-Tags werden gesetzt, wenn diese eine zentrale Rolle in dem Artikel spielen.
• Sie werden nicht gesetzt, wenn sie nicht als solche relevant sind, also für die Geschichte eine austauschbare Nebenrolle spielen.
• Der Autor kann sich entscheiden, den Tag nicht zu setzen obwohl er es könnte.
• Es wird empfohlen, nicht mehr als drei Charakter- und/oder MTF-Tags unter einem Artikel zu verwenden.
• Neue Charakter- und MTF-Tags können erstellt werden, wenn diese in 5 Artikeln von mindestens 3 Autoren eine maßgebliche Rolle gespielt haben. Dies erfordert überdies eine administrative Freigabe.
• Charakter-Tags werden mit dem Primärtitel der Figur verwendet (z.B. agent-smith, doktor-moreau)

Änderungsprotokoll

15.05.2021

• Sektion "Tagregeln", Abschnitt "Charakter- und MTF-Tags" hinzugefügt
• Sektion "Tagregeln", Abschnitt "Vorgeschriebene Tags", Zeile "Datenblätter" hinzugefügt

29.04.2021

• Link zu den englischsprachigen Regeln eingefügt

21.04.2021

• Passwort des Hauptwikis weiter nach oben verschoben (damit die die nur lesen wollen es leichter finden)
• Passwort der Sandbox unten in den Regeln untergebracht (damit die die schreiben wollen kein Rätsel mehr lösen, aber dennoch die Regeln ganz lesen müssen)

22.03.2021

• Inhaltliche Korrektur in den Lizenzregeln

20.03.2021

• Grundlegende Überarbeitung
• Zusammenfassung der Regeln in ein Dokument. Diesmal wirklich
• Streichung redundanter Regeln
• Neuformulierung zahlreicher Regeln zur besseren Verständlichkeit
• Anpassung der Regeln an den praktizierten Status Quo

31.05.2020

Neues Feedbacksystem
Verbot von Bezahldiensten. Diese Regel wird aufgrund eines solchen Falls in einem anderen Wiki eingeführt.

06.08.2019

Übersetzungen -> Grundbegriffe -> „Caucasian“ hinzugefügt.

05.08.2019

Neue Artikel -> Freigaben -> 1.: Änderung des Freigabesystems eingepflegt.

07.07.2019

Aufgrund der Menge, werden Änderungen und Neuformulierungen die keine wirklichen Neuerungen bringen, sowie Regeln die schon länger bekannt, aber nirgendwo anständig festgehalten, oder irgendwo versteckt waren, hier nicht genannt. Bitte lest die Regeln aufmerksam und vollständig durch. Dies sind die geltenden Regeln, solltet ihr Widersprüche zu anderswo erwähnten Regeln finden, meldet das bitte, und richtet euch nur nach diesem Dokument. Es kann an anderer Stelle ergänzende Regeln geben, aber keine die dieses Dokument außer Kraft setzen.
Allgemeine Änderungen:

• Zusammenfassung der Regeln in ein Dokument
• Streichung redundanter Regeln
• Neuformulierung zahlreicher Regeln zur besseren Verständlichkeit

Neue Regeln:

• Neue Artikel
  • Medien
    • Regel 2.
    • Regel 3.
    • Regel 4.
  • Themes und CSS
    • Punkt 3.

Geänderte Regeln:

• Neue Artikel
  • Neue Artikel erstellen
    • Regel 4. (war bisher optional)