From 4b1a9203c547c019fc5398082ae19a3f3d4c3efe Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:41:15 -0500 Subject: initial commit --- .../community/bleibe_auf_dem_laufenden/index.html | 42 ++ files/de/mdn/community/index.html | 80 +++ files/de/mdn/contribute/feedback/index.html | 51 ++ files/de/mdn/contribute/getting_started/index.html | 125 +++++ .../convert_code_samples_to_be_live/index.html | 28 ++ .../howto/do_a_technical_review/index.html | 54 ++ .../howto/do_an_editorial_review/index.html | 49 ++ .../howto/document_a_css_property/index.html | 89 ++++ .../howto/erstellung_eines_mdn_profils/index.html | 50 ++ files/de/mdn/contribute/howto/index.html | 13 + .../index.html" | 81 +++ .../howto/set_the_summary_for_a_page/index.html | 54 ++ files/de/mdn/contribute/howto/tag/index.html | 429 ++++++++++++++++ files/de/mdn/contribute/index.html | 91 ++++ files/de/mdn/contribute/localize/index.html | 29 ++ .../localize/translating_pages/index.html | 58 +++ files/de/mdn/contribute/zu_tun_im_mdn/index.html | 27 + files/de/mdn/guidelines/index.html | 14 + files/de/mdn/guidelines/style_guide/index.html | 560 +++++++++++++++++++++ files/de/mdn/index.html | 33 ++ .../kuma/beheben_von_kumascript_fehlern/index.html | 63 +++ files/de/mdn/kuma/index.html | 28 ++ files/de/mdn/nutzer_leitfaden/index.html | 8 + files/de/mdn/structures/index.html | 10 + .../kompatibilitaets_tabellen/index.html | 500 ++++++++++++++++++ "files/de/mdn/\303\274ber/index.html" | 99 ++++ "files/de/mdn/\303\274ber/link_zu_mdn/index.html" | 82 +++ 27 files changed, 2747 insertions(+) create mode 100644 files/de/mdn/community/bleibe_auf_dem_laufenden/index.html create mode 100644 files/de/mdn/community/index.html create mode 100644 files/de/mdn/contribute/feedback/index.html create mode 100644 files/de/mdn/contribute/getting_started/index.html create mode 100644 files/de/mdn/contribute/howto/convert_code_samples_to_be_live/index.html create mode 100644 files/de/mdn/contribute/howto/do_a_technical_review/index.html create mode 100644 files/de/mdn/contribute/howto/do_an_editorial_review/index.html create mode 100644 files/de/mdn/contribute/howto/document_a_css_property/index.html create mode 100644 files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html create mode 100644 files/de/mdn/contribute/howto/index.html create mode 100644 "files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" create mode 100644 files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html create mode 100644 files/de/mdn/contribute/howto/tag/index.html create mode 100644 files/de/mdn/contribute/index.html create mode 100644 files/de/mdn/contribute/localize/index.html create mode 100644 files/de/mdn/contribute/localize/translating_pages/index.html create mode 100644 files/de/mdn/contribute/zu_tun_im_mdn/index.html create mode 100644 files/de/mdn/guidelines/index.html create mode 100644 files/de/mdn/guidelines/style_guide/index.html create mode 100644 files/de/mdn/index.html create mode 100644 files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html create mode 100644 files/de/mdn/kuma/index.html create mode 100644 files/de/mdn/nutzer_leitfaden/index.html create mode 100644 files/de/mdn/structures/index.html create mode 100644 files/de/mdn/structures/kompatibilitaets_tabellen/index.html create mode 100644 "files/de/mdn/\303\274ber/index.html" create mode 100644 "files/de/mdn/\303\274ber/link_zu_mdn/index.html" (limited to 'files/de/mdn') diff --git a/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html b/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html new file mode 100644 index 0000000000..cd5c500e41 --- /dev/null +++ b/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html @@ -0,0 +1,42 @@ +--- +title: Bleibe auf dem Laufenden +slug: MDN/Community/Bleibe_auf_dem_Laufenden +tags: + - Anfänger + - Community + - Guide + - MDN-Meta +translation_of: MDN/Community/Whats_happening +--- +
{{MDNSidebar}}

MDN wird von der Mozilla Developer Network Community (englisch) erstellt. Hier sind ein paar Kanäle, über die wir Informationen darüber teilen, an was wir arbeiten.

+ +

Blogs

+ +
+
Mozilla Hacks (englisch)
+
Neuigkeiten und ausführliche Berichte zu Web- und Mozilla-Technologien und -Features.
+
Entwickler einbinden (englisch)
+
Förderung der Aktivitäten und Diskussionen zwischen der an MDN beteiligten Community bei Mozilla.
+
+ +

Streams

+ + + +

Statusboards und Dashboards

+ +

Das MDN-Dokumentationsteam unterhält ein Trello board (englisch), auf dem unsere Projekte verwaltet werden. Dieses Board ist nur lesbar, erlaubt es dir jedoch, zu sehen, an was gearbeitet wird und was wir hoffen, bald angehen zu können, und ermöglicht es dir, herauszufinden, wo du helfen kannst. Dieser Artikel erklärt, wie dieses Board verwendet wird.

+ +

Außerdem solltest du einen Blick auf die Dokumentationsstatus-Seiten werfen, um zu sehen, was aktuell in Bezug zu allen MDN-Inhalten passiert. Du kannst sehen, welche Artikel geschrieben oder aktualisiert werden müssen, welche Themen die meiste Hilfe benötigen und viel, viel mehr.

+ +

MDN-Meetings

+ +

Es gibt einige regelmäßige Meetings, um den Fortschritt verschiedener MDN-Projekte und -Prozesse zu verfolgen und zu teilen. Diese sind auf der MDN-Meetings-Wikiseite (englisch) beschrieben.

+ +

Um einen allgemeinen Sinn dafür zu bekommen, was aktuell passiert, sollte man am MDN-Community-Meeting teilnehmen, welches alle zwei Wochen mittwochs, 10:00 US-Pazifikzeit (UTC-0800 Oktober-März, UTC-0700 März-Oktober) im #mdn IRC-Kanal stattfindet. Siehe die MDN-Community-Meetings-Wikiseite für Termine und Notizen zu vergangenen Meetings.

+ +

Der Kalender für öffentliche MDN-Events (englisch) beinhaltet MDN-Community-Meetings, Docsprints und andere MDN-bezogene Ereignisse. Falls du ein Meeting siehst, das im "mdn"-Kanal unseres Vidyo-Videokonferenzsystems stattfindet, kannst du an der Konversation im Web teilnehmen (englisch).

diff --git a/files/de/mdn/community/index.html b/files/de/mdn/community/index.html new file mode 100644 index 0000000000..f8df9274e7 --- /dev/null +++ b/files/de/mdn/community/index.html @@ -0,0 +1,80 @@ +--- +title: Tritt der MDN-Gemeinschaft bei +slug: MDN/Community +tags: + - Community + - Guide + - Landing + - MDN Meta + - Meeting +translation_of: MDN/Community +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-de/docs/MDN")}}
+ +

MDN ist mehr als ein Wiki: Es ist eine Gemeinschaft von Entwicklern, die zusammenarbeiten um MDN zu einer eigenständigen Ressource für Entwickler, die openWeb-Technologien nutzen, zu machen. Die "Arbeit" wird auf der  MDN-Seite gemacht, aber die "Community" funktioniert auch (asynchron) durch Diskussionen und (synchron) durch Online-Chats.

+ +

Wir würden uns freuen, wenn Du beim MDN mitmachen würdest, aber noch mehr, wenn Du bei der MDN-Community mitmachen würdest. Hierunter kannst Du lesen, wie man sich in wenigen Schritten anmeldet:

+ +
    +
  1. Erstelle ein MDN-Konto.
    2. +
  2. Abonniere die dev-mdc Verteilerliste.
    3. +
  3. Gehe zu IRC.
    4. +
+ +

Erstelle ein MDN-Konto

+ +

{{page("/en-US/docs/Project:MDN/Contributing/Getting_started", "Creating an account") }}

+ +

Unseren Verteiler-Listen beitreten

+ +

Zum Informationsaustausch und für Diskussionen hat Mozilla mehrere nützliche Mailinglisten. Insbesondere für MDN sind das:

+ +
+
dev-mdc
+
In dieser Liste diskutieren wir über die Dokumentation auf MDN. Wir sprechen über Änderungen und Verbesserungen die wir gemacht haben und wir klären, wer welche Inhalte bearbeiten möchte. Wir empfehlen dringend, dass Du dieser Liste beitrittst, wenn Du Dich ernsthaft für die Dokumentation auf MDN interessierst!
+
dev-mdn
+
In dieser Liste führen wir Diskussionen über die Entwicklung der MDN zugrunde liegenden Plattform Kuma. Wenn Du neugierig auf die Entwicklung und Arbeit hinter den Kulissen bist und am Entscheidungsprozess über die Plattform beteiligt sein möchtest, oder an Verbesserungen für die Plattform arbeiten willst, solltest Du Dich auf jeden Fall in dieser Liste engagieren.
+
mdn-drivers
+
Diese Mailingliste wird verwendet, um über die Prioritäten für die MDN-Entwicklung zu entscheiden. Es dient in der Regel dazu zu diskutieren, was weitergehend bearbeitet werden soll und gehen wir das Entwicklungsteam Aufmerksamkeit zu erregen, wenn ein ernstes Problem muss behoben werden, nachdem wir einen Bug für das Thema eingereicht haben.
+
+ +

Es gibt auch ein paar Listen speziell für MDN Lokalisierung Gemeinschaften. Wenn Ihre Gemeinde sehr groß und aktiv ist, erhalten Sie wahrscheinlich eine Liste erstellt für Ihre Gemeinde; Fragen Sie uns und wir schauen hinein. Derzeit haben diese Sprachen Listen : Spanish, Japanese, und Portuguese.

+ +

Warum "Dev-Mdc"? In der Vergangenheit wurde dies als "Mozilla Developer Center" oder MDC bezeichnet. Die Mailing-Liste stammt aus jener Zeit, so ist es Dev-Mdc. Es gibt auch eine Dev-Mdn Mailing-Liste für die Diskussion ist über die Entwicklung der Kuma-Plattform, die MDN läuft auf. Du bist herzlich eingeladen, die auch, aber es ist nicht notwendig, wenn Sie nur in MDN Inhalt interessiert.

+ +

In den IRC gehen

+ +

Der Internet Relay Chat (IRC) ist unserer bevorzugter Weg um uns täglich abzusprechen und in Echtzeit Diskussionen unter Community-Mitgliedern zu führen. Wir nutzen verschiedene Kanäle um Diskussionen zu führen, die mit dem MDN zu tun haben.

+ +
+
#devmo
+
Internet Relay Chat (IRC) ist unsere bevorzugte Methode für die täglichen Chat und Diskussionen unter den Community-Mitgliedern in Echtzeit. Wir verwenden ein paar Kanäle für Diskussionen im Zusammenhang mit MDN.
+
#mdn
+
MDN ist mehr als nur die Dokumentation, und aus diesem Grund haben wir einen Kanal für das Gespräch über die größeren MDN-Projekts. Das ist #mdn.
+
#mdndev
+
dieses Kanals ist unsere primäre Kanal für die Erörterung des Dokumentation Inhalts selbst. Wir sprechen über das Schreiben, Organisation von Inhalten, und so weiter. Wir haben auch "Wasser-Kühler" Gespräche hier – es ist ein Weg, unsere Community in Kontakt zu bleiben und einfach nur rumhängen kann.
+
+ +

Diese Kanäle sind am ehesten in Nordamerika unter der Woche aktiv sein.

+ +

Erfahre mehr über IRC, wenn Du damit nicht vertraut bist. ChatZilla ist ein IRC-Client implementiert als Firefox Add-on, das macht es schnell und einfach zu installieren und starten Sie mit it.

+ +

Nimm an unseren zweiwöchentlichen Besprechungen (und anderen Veranstaltungen) teil

+ +

Jede zweite Woche, hält die MDN Gemeinschaft ein IRC-basierten Live Meeting Notizen austauschen, reden, was wir getan haben und klären wir für die nächsten zwei Wochen zu tun möchten. Wir sprechen auch über Entwicklungspläne für die MDN-Plattform selbst und oft Updates über neue und kommende Features der Website erhalten. Dies sind lockere, lustige treffen, und jeder ist herzlich willkommen.
+
+ Auf der Seite MDN Gemeindeversammlungen auf der Mozilla-Wiki für Details über den Zeitplan sowie die Tagesordnungen und Notizen für vergangene und geplante Veranstaltungen.

+ +

Auf der Seite MDN Community Meetings auf der Mozilla-Wiki für Details über den Zeitplan sowie die Tagesordnungen und Notizen für vergangene und geplante Veranstaltungen.

+ +

Die MDN Events calendar für diese und andere Meetings, Doc Sprints und anderen Veranstaltungen zu sehen.

+ +

Nächste Schritte

+ + diff --git a/files/de/mdn/contribute/feedback/index.html b/files/de/mdn/contribute/feedback/index.html new file mode 100644 index 0000000000..fcc2560b5d --- /dev/null +++ b/files/de/mdn/contribute/feedback/index.html @@ -0,0 +1,51 @@ +--- +title: Feedback zu MDN senden +slug: MDN/Contribute/Feedback +tags: + - Dokumentation + - Guide + - MDN + - MDN-Meta +translation_of: MDN/Contribute/Feedback +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/de/docs/MDN")}}
+ +

Willkommen auf MDN! Falls du Verbesserungsvorschläge für oder Probleme mit der Benutzer von MDN hast, ist dies der richtige Ort. Dass du Interesse daran zeigst, Feedback zu geben, macht dich mehr Teil der Mozilla-Community, und wir danken dir im Voraus für dein Interesse.

+ +

Du hast mehrere Möglichkeiten, deine Eindrücke zu schildern; dieser Artikel hilft dir dabei.

+ +

Die Dokumentation aktualisieren

+ +

Zuallererst, falls du ein Problem im Zusammenhang mit der Dokumentation gesehen hast, kannst du ihn gerne selbst korrigieren. Melde dich an, indem du GitHub verwendest, dann klicke auf einen blauen Bearbeiten-Button, um den Editor zu öffnen und damit an der MDN-Dokumentation mitzuwirken. Die Dokumentation hier ist in einem Wiki und wird durch ein Team von Freiwilligen und bezahlten Arbeitskräften betreut, seit also nicht schüchtern — deine Grammatik muss nicht perfekt sein. Wenn du einen Fehler machen solltest, werden wir ihn beheben; keine Sorge!

+ +

Für weitere Informationen über die Mitwirkung zur MDN-Dokumentation siehe:

+ + + +

Nimm an der Konversation teil

+ +

Sprich mit uns! Es gibt mehrere Wege, um mit anderen Leuten, die an MDN-Inhalten arbeiten, in Kontakt zu treten.

+ +

(Synchron) Chat

+ +

+

(Asynchron) Diskussionen

+ + +

Längere Diskussionen finden in unserem MDN-Diskussionsforum (englisch) statt. Du kannst über die E-Mail-Adresse mdn@mozilla-community.org ins Forum posten. Falls du dem Forum beitritts, kannst du zudem auswählen, ob du Benachrichtigungen über Diskussionen via E-Mail erhalten willst.

+ +

Fehler melden

+ +

Dokumentationsfehler

+ +

Falls du einen Fehler in der Dokumentation siehst und ihn aus irgendeinem Grund nicht selbst beheben kannst, kannst du einen Fehlerbericht erstellen (englisch)! Du kannst dieses Formular für beliebige Dokumentationsprobleme verwenden, egal ob es eine einfache Korrektur ist oder eine Anfrage für einen komplett neuen Inhalt. Wie zuvor erwähnt, laden wir dich dazu ein, die Änderungen selbst beizutragen, jedoch steht dir diese Option ebenfalls offen.

+ +

Seitenfehler

+ +

Falls du auf Probleme mit der MDN-Webseite stößt oder Ideen für neue Features für die Seite hast, kannst du ein Ticket an das MDN-Entwicklerteam stellen (englisch).

diff --git a/files/de/mdn/contribute/getting_started/index.html b/files/de/mdn/contribute/getting_started/index.html new file mode 100644 index 0000000000..a1f27d9d62 --- /dev/null +++ b/files/de/mdn/contribute/getting_started/index.html @@ -0,0 +1,125 @@ +--- +title: Erste Schritte auf MDN +slug: MDN/Contribute/Getting_started +tags: + - Documentation + - Getting Started + - Guide + - MDN + - MDN Project + - New Contributors +translation_of: MDN/Contribute/Getting_started +--- +
{{MDNSidebar}}

Wir sind eine offene Gemeinschaft von Entwicklern, die Ressourcen für ein besseres Internet ohne Rücksicht auf Marke, Browser oder Plattform erstellen. Jeder kann dazu einen Beitrag leisten und jeder, der uns dabei hilft, macht uns stärker. Gemeinsam können wir auch in Zukunft Neuerungen im Internet zum Nutzen Aller voranbringen. Es beginnt hier, mit Ihnen.

+ +

Alle Bestandteile von MDN (Dokumentationen, Demos und die Webseiten an sich) werden von einer offenen Gemeinschaft von Entwicklern erstellt. Bitte schließen Sie sich uns an!

+ +

3 einfache Schritte um bei MDN mitzumachen

+ +

MDN ist ein Wiki, dem jeder Inhalte hinzufügen und diese bearbeiten kann. Sie müssen kein Programmierer sein oder besonders viel über Technologien wissen. Es gibt eine ganze Reihe von Aufgaben, die erledigt werden müssen, vom Einfachen (Korrekturlesen und Beheben von Tippfehlern) bis zum Komplexen (API Dokumentationen schreiben).

+ +

Einen Beitrag zu leisten ist einfach und sicher. Wenn Sie einen Fehler machen, wird dieser schnell behoben werden. Auch wenn Sie sich nicht sicher sind, wie manche Dinge aussehen sollen oder Ihre Grammatik nicht allzu gut ist, zerbrechen Sie sich darüber nicht den Kopf. Wir haben ein Team von Leuten, deren Job es ist zu gewährleisten, dass die Inhalte auf MDN so gut wie möglich sind. Jemand wird da sein um sicherzustellen, dass Ihre Arbeit ordentlich und gut formuliert ist.

+ +

Schritt 1: Legen Sie ein Konto für MDN an

+ +

Um mit Ihren Beiträgen auf MDN zu beginnen, benötigen Sie ein Konto für MDN. Näheres erfahren Sie unter Anlegen eines Accounts.

+ +

Schritt 2: Suchen Sie sich eine zu erledigende Aufgabe

+ +

Sobald Sie eingeloggt sind, lesen Sie die Beschreibungen der verschiedenen Arten von Aufgaben in der Liste unten und entscheiden Sie, welche Sie davon am Meisten reizt. Sie können sich jede Aufgabe die Ihnen gefällt aussuchen, um mit Ihrem Beitrag zu beginnen.

+ +

Schritt 3: Erledigen Sie die Aufgabe

+ +

Sobald Sie entschieden haben, welche Art von Aufgabe Sie erledigen wollen, suchen Sie nach einer Seite, einem Code Beispiel o. ä. an dem Sie arbeiten wollen und legen Sie einfach los!

+ +

Machen Sie sich keine Gedanken, ob es perfekt ist! Andere Mitwirkende von MDN sind da, um durchgerutschte Fehler zu beheben. Möchten Sie lieber erst experimentieren bevor Sie etwas “in Echt” machen, können Sie die Sandbox Seite editieren. Bei auftauchenden Fragen finden Sie auf der Community Seite Informationen über Mailing Listen und Chat Kanäle, auf denen Sie Antworten erhalten können.

+ +

Wenn Sie fertig sind, können Sie sich gerne eine weitere Aufgabe aussuchen oder schauen Sie unten was Sie noch auf MDN tun können.

+ +

Mögliche Arten von Aufgaben

+ +

Abhängig von Ihren Fähigkeiten und Interessen gibt es viele Möglichkeiten, um zu MDN beizutragen. Obwohl manche Aufgaben gewaltig sind, haben wir auch eine Menge einfacher Arbeiten zur Auswahl. Viele davon sind in fünf Minuten (oder weniger!) erledigt. Zusätzlich zur Aufgabe und einer kurzen Beschreibung finden Sie die ungefähre Zeit, die jede Art von Aufgabe normalerweise erfordert, mit angegeben.

+ +

Option 1: Ich mag Worte

+ +

Sie können uns bei der Durchsicht und beim Bearbeiten bestehender Dokumentationen und beim Anlegen zutreffender Schlagwörter behilflich sein.

+ + + +
Hinweis: Wenn Sie Artikel rezensieren oder neue Artikel verfassen, bitten wir Sie den Style Guide einzusehen. Somit wird gewährleistet, dass alle Artikel einheitlich bleiben.
+ +

Option 2: Ich mag Code

+ +

Wir brauchen mehr Code Beispiele! Außerdem können Sie uns beim Aufbau unserer Webseiten Plattform Kuma behilflich sein!

+ + + +

Option 3: Ich mag sowohl Worte als auch Code

+ +

Wir haben Aufgaben, die sowohl technische als auch sprachliche Fähigkeiten erfordern, wie z.B. neue Artikel verfassen, Durchsichten auf technische Genauigkeit oder das Anpassen von Dokumenten.

+ + + +

Option 4: Ich möchte MDN in meiner Sprache

+ +

Sämtliche Lokalisierungs- und Übersetzungsarbeiten auf MDN werden von unserer phantastischen Gemeinschaft von Freiwilligen geleistet.

+ + + +

Option 5: Ich habe eine falsche Information gefunden, aber ich weiß nicht wie ich den Fehler beheben kann

+ +

Sie können Probleme melden indem Sie einen Dokumentations-Bug anlegen. (5 Minuten)

+ +

Verwenden Sie diese Feldwerte:

+ + + + + + + + + + + + + + + + + + + + + + + + +
Bugzilla FeldWert
productEntwicklerdokumentation
component[Wählen Sie einen geeigneten Bereich für das Thema oder "General", wenn Sie sich nicht sicher sind oder den richtigen Bereich nicht finden können]
URLDie Seite auf der Sie das Problem gefunden haben
DescriptionSo viel Sie über das Problem wissen oder Zeit haben, das Problem zu beschreiben und wo korrekte Informationen zu finden sind. Das können sowohl Menschen ("sprich mit so-und-so") als auch Web-Links sein.
+ +

Was Sie noch auf MDN tun können

+ + diff --git a/files/de/mdn/contribute/howto/convert_code_samples_to_be_live/index.html b/files/de/mdn/contribute/howto/convert_code_samples_to_be_live/index.html new file mode 100644 index 0000000000..4c4a0a283e --- /dev/null +++ b/files/de/mdn/contribute/howto/convert_code_samples_to_be_live/index.html @@ -0,0 +1,28 @@ +--- +title: How to convert code samples to be "live" +slug: MDN/Contribute/Howto/Convert_code_samples_to_be_live +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +--- +
{{MDNSidebar}}

MDN besitzt ein "live sample"-System, bei dem die Ausgabe des angezeigten Codes direkt angezeigt wird. Allerdings gibt es noch viele Codebeispiele, die dieses System noch nicht nutzen und noch konvertiert werden müssen.

+ +

Live-Beispiele, die dir direkt die Ausgabe anzeigen, machen Dokumentationen dynamischer und informativer. Der Leitfaden beschreibt, wie die "live"-Funktionalität zu bereits bestehenden Beispielen hinzugefügt werden kann.

+ + + +
    +
  1.   Wähle einen Artikel mit dem Tag "NeedsLiveSample" aus
    2. +
  2. Konvertiere das Codebeispiels
    3. +
  3. Lösche alle Bilder oder  Texte, auf denen die Ausgabe gezeigt wird
    4. +
+ +
+
Wo muss dies gemacht werden?
+
Bei Artikeln mit dem Tag "NeedsLiveSample".
+
Was musst du können um diese Aufgabe zu erledigen?
+
Welche Schritte müssen  unternommen werden?
+
+ +

Für weitere Informationen um das Thema Erstellen und Bearbeiten von Live-Beispielen, schau dir Using the live sample system an

diff --git a/files/de/mdn/contribute/howto/do_a_technical_review/index.html b/files/de/mdn/contribute/howto/do_a_technical_review/index.html new file mode 100644 index 0000000000..0f52932293 --- /dev/null +++ b/files/de/mdn/contribute/howto/do_a_technical_review/index.html @@ -0,0 +1,54 @@ +--- +title: Wie eine technische Überprüfung gemacht wird +slug: MDN/Contribute/Howto/Do_a_technical_review +translation_of: MDN/Contribute/Howto/Do_a_technical_review +--- +
{{MDNSidebar}}

Technische Überprüfungen beinhalten die Prüfung der technischen Genauigkeit und Vollständigkeit eines Artikels und gegebenenfalls dessen Korrektur. Falls ein Autor eines Artikels will, dass jemand anderes den technischen Inhalt eines Artikels überprüft, so kann er das Kontrollkästchen "Technisch – Quelltext-Ausschnitte, APIs oder Technologien" während der Bearbeitung anhaken. Oftmals kontaktiert der Autor eine bestimmte Person, damit diese die technische Überprüfung durchführt, jedoch kann jeder mit technischer Expertise im jeweiligen Bereich diese durchführen.

+ +

Dieser Artikel beschreibt, wie man bei einer technischen Überprüfung vorgeht, und hilft somit, sicherzustellen, dass die Inhalte auf MDN korrekt sind.

+ + + + + + + + + + + + + + + + + + + + +
Was ist die Aufgabe?Überprüfen und korrigieren von Artikeln auf technische Genauigkeit und Vollständigkeit
Wo muss sie gemacht werden?Innerhalb bestimmter Artikel, die markiert wurden, dass sie eine technische Überprüfung benötigen.
Was muss ich wissen, um die Aufgabe zu erledigen? +
    +
  • Expertenwissen im Bereich, den der Artikel, den du überprüfst, umfasst.
    • +
  • Fähigkeit, einen Wikiartikel auf MDN zu bearbeiten.
    • +
+
Was sind die auszuführenden Schritte? +
    +
  1. Wähle einen Artikel zur Überprüfung: +
      +
    1. Schau dir die Liste der Artikel, die technische Überprüfung benötigen, an. Diese listet alle Seiten auf, für die eine redaktionelle Überprüfung angefordert wurde.
      2. +
    2. Wähle eine Seite, mit dessen Thema du dich auskennst.
      3. +
    3. Klicke auf den Artikellink, um die Seite zu laden.
      4. +
    +
    2. +
  2. Sobald die Seite geladen ist, klicke auf die BEARBEITEN Schaltfläche oben auf der Seite; dies startet den MDN Editor. Zögere nicht, zu einer anderen Seite zu wechseln, falls dir die erste nicht zusagt.
    3. +
  3. Während des Lesens des Artikels korrigiere alle technischen Informationen, die fehlerhaft sind, und füge wichtige Informationen hinzu, die fehlen.
    4. +
  4. Gib einen Kommentar zur Version des Artikels ein, der beschreibt, was du getan hast; beispielsweise 'Technische Überprüfung durchgeführt.' Falls du Informationen korrigiert hast, füge dies deinem Kommetar hinzu, beispielsweise 'Technische Überprüfung: Parameterbeschreibungen korrigiert.'
    5. +
  5. Klicke auf die ÄNDERUNGEN SPEICHERN Schaltfläche.
    6. +
  6. Sobald der korrigierte Artikel auf dem Bildschirm erscheint nachdem der Editor geschlossen wurde, setze einen Haken bei Technisch (unterhalb Die folgenden Überprüfungen wurden angefordert) und klicke auf ÜBERPRÜFUNG ABSENDEN.
    7. +
  7. +

    Fertig!

    +
    8. +
+
+ +

 

diff --git a/files/de/mdn/contribute/howto/do_an_editorial_review/index.html b/files/de/mdn/contribute/howto/do_an_editorial_review/index.html new file mode 100644 index 0000000000..2c8df95aa6 --- /dev/null +++ b/files/de/mdn/contribute/howto/do_an_editorial_review/index.html @@ -0,0 +1,49 @@ +--- +title: Wie eine redaktionelle Überprüfung gemacht wird +slug: MDN/Contribute/Howto/Do_an_editorial_review +translation_of: MDN/Contribute/Howto/Do_an_editorial_review +--- +
{{MDNSidebar}}

Redaktionelle Überprüfungen beinhalten die Korrigierung von Tipp-, Rechtschreib-, Grammatik- oder Benutzungsfehlern - also ausdrücklich keine inhaltliche Zensur - in einem Artikel. Nicht alle Mitwirkenden sind Sprachexperten, haben jedoch durch ihr Wissen äußerst nützliche Artikel beigetragen, welche korrekturgelesen werden müssen. Dies findet in der redaktionellen Überprüfung statt.

+ +

Dieser Artikel beschreibt, wie man bei einer redaktionellen Überprüfung vorgeht, und hilft somit, sicherzustellen, dass die Inhalte auf MDN korrekt sind.

+ + + + + + + + + + + + + + + + + + + + +
Was ist die Aufgabe?Korrekturlesen von Artikeln, die markiert wurden, dass sie eine redaktionelle Überprüfung benötigen.
Wo muss sie gemacht werden?Innerhalb bestimmter Artikel, die markiert wurden, dass sie eine redaktionelle Überprüfung benötigen.
Was muss ich wissen, um die Aufgabe zu erledigen?Du benötigst gute Grammatik- und Rechtschreibkenntnisse in Deutsch.
Was sind die auszuführenden Schritte? +
    +
  1. Wähle einen Artikel zur Überprüfung: +
      +
    1. Schau dir die Liste der Artikel, die redaktionelle Überprüfung benötigen, an. Diese listet alle Seiten auf, für die eine redaktionelle Überprüfung angefordert wurde.
      2. +
    2. Wähle eine Seite, die eine englische Überschrift hat und deren Pfad nicht mit Template: beginnt.
      3. +
    3. Klicke auf den Artikellink, um die Seite zu laden.
      4. +
    +
    2. +
  2. Sobald die Seite geladen ist, klicke auf die BEARBEITEN Schaltfläche oben auf der Seite; dies startet den MDN Editor. Zögere nicht, zu einer anderen Seite zu wechseln, falls dir die erste nicht zusagt.
    3. +
  3. Korrigiere alle Tipp-, Rechtschreib- und Grammatik- oder Benutzungsfehler, die du siehst.
    4. +
  4. Gib einen Kommentar zur Version des Artikels ein; beispielsweise 'Redaktionelle Überprüfung: Tipp-, Grammatik- und Rechtschreibfehler korrigiert.'
    5. +
  5. Klicke auf die ÄNDERUNGEN SPEICHERN Schaltfläche.
    6. +
  6. Sobald der korrigierte Artikel auf dem Bildschirm erscheint nachdem der Editor geschlossen wurde, setze einen Haken bei Redaktionell (unterhalb Die folgenden Überprüfungen wurden angefordert) und klicke auf ÜBERPRÜFUNG ABSENDEN.
    7. +
  7. +

    Fertig!

    +
    8. +
+
+ +

 

diff --git a/files/de/mdn/contribute/howto/document_a_css_property/index.html b/files/de/mdn/contribute/howto/document_a_css_property/index.html new file mode 100644 index 0000000000..3270d75064 --- /dev/null +++ b/files/de/mdn/contribute/howto/document_a_css_property/index.html @@ -0,0 +1,89 @@ +--- +title: How to document a CSS property +slug: MDN/Contribute/Howto/Document_a_CSS_property +tags: + - CSS + - Guide + - Howto + - MDN Meta + - NeedsTranslation + - TopicStub +translation_of: MDN/Contribute/Howto/Document_a_CSS_property +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

As the CSS standards evolve, new properties are always being added. The MDN CSS Reference needs to be kept up to date with these developments. This document gives step-by-step instructions for creating a CSS property reference page.

+ +

Each CSS property reference page follows the same structure. This helps readers find information more easily, especially once they are familiar with the standard reference page format.

+ +

Step 1 — Decide which property to document

+ +

First, you will need to decide which property to document. The CSS Documentation status page lists properties that need to be documented. For details about the CSS property you will need to find a relevant specification for it (e.g., a W3C specification, a Mozilla Wiki page, or a bug report for a non-standard property used in rendering engines like Gecko or Blink).

+ +
+

Pro tips:

+ + +
+ +

Step 2 — Check the database of CSS properties

+ +

Several characteristics of a CSS property, such as its syntax or if it can be animated, are mentioned in several pages and are therefore stored in an ad-hoc database. Macros that you'll use on the page need information about the property that is stored there, so start by checking that this information is there.

+ +

If not, contact an admin or a power user, either in the MDN Web Docs (Matrix) chat room, or, if nobody is available, by filing a bug.

+ +

Step 3 — Creating the CSS property page

+ +

Preparations finished! Now we can add the actual CSS property page. The easiest way to create a new CSS property page is to copy the content of an existing page and to edit it. We will go through the different steps now.

+ +
+

Cloning a page is currently broken on MDN. That's why we need to go through these somewhat more complex steps. Please vote for ({{bug(870691)}}).

+
+ +
    +
  1. Clone the following page, set the title to your-property (without capitals) and the slug to Web/CSS/your-property.
    2. +
  2. Change the summary to fit, but keep it starting the same way : "The your-property CSS property…". Explain briefly what this property is for.
    3. +
  3. If the property is not experimental, remove the \{{SeeCompatTable}} macro. The purpose of this macro is to alert developers to the possibility that the feature may not yet have consistent support across browsers, and may change in the future as its specificaton evolves. Deciding whether a feature is experimental is a matter of judgement, and should include factors like: +
      +
    • Is the feature supported by several browsers?
      • +
    • Is the feature prefixed or behind a preference?
      • +
    • Is there any reason to think that the implementation of the feature will change in the future?
      • +
    +
    4. +
  4. Replace the parameter of the \{{cssinfo("animation-name")}} macro by the name of the CSS property you are documenting. This will allow you to build the summary box using the data you entered in step 2.
    5. +
  5. Replace the example of the syntax by relevant ones. Keep them very simple and don't forget that a lot of people don't understand a formal syntax so it needs to be simple and exhaustive. Keep the inherit, initial, and unset keywords examples at the end. It reminds users that these are valid values, too.
    6. +
  6. Under the chapter Values, put the meaning of each value. If it is a keyword, don't forget to mark it as code (select it and press CTRL-O). Each description should start by "Is a" followed by the type of the value, or indicating it is a keyword.
    7. +
  7. Clear the Examples chapter, we will add them at the end!
    8. +
  8. Update the specification table. For information about how to do it, read this tutorial.
    9. +
  9. Update the compatibility information. For information about how to do it, read this tutorial.
    10. +
  10. Update the See also section with relevant links. Do not link to specs here and usually link to internal documents. External documents are welcome, but only if they bring really good information. There are spam or SEO links often, so don't worry if external links are removed sometimes. Just start the discussion if you still find it useful and want to see it back.
    11. +
  11. Add the relevant tags: you need to add CSS, CSS Property, and Reference. You also need to add Experimental or Non-standard if this is the case. Finally you also need to add a CSS XYZ tag, where XYZ stands for the group of CSS properties it belongs to. It is often the spec short name. All these tags are used to generate quicklinks and other niceties.
    12. +
+ +

At any point, you can save by hitting the SAVE button. You can continue to edit right along. If you haven't saved your page until now, please do so! :-)

+ +

The last step is to add Examples. To do that follow this tutorial about live samples. Don't forget that we are in a document explaining one single property: you need to add examples that show how this property is working in isolation, not how the whole specification is used. That means, examples for list-style-type will show what the different values generate, but not how to combine it with other property, pseudo-classes or pseudo-elements to generate nice effects; tutorials and guide can be written to show more.

+ +

Step 4 — Getting a review

+ +

You have documented your CSS property! Congratulations!

+ +

In order to have a good quality and consistency throughout the MDN CSS reference, it is good practice to request a review. Just click on the checkbox at the bottom of the article (in edit mode), and, optional, if you want to have a more personal review helping you to improve editorial skills, ask for it on the MDN forum.

+ +

Step 5 — Integrating the new page in the MDN

+ +

Now that your page is created, you want it to be found by the readers. Adding tags helped about this already as it allowed it to appear in the quicklinks to related CSS pages. Also you want it to appear on the CSS index page. If the newly documented property is on the standard track and at least one major browser is implementing it, it deserves to be listed this. Only administrator can add it there, so contact the CSS driver on IRC (currently at #mdn ping teoli) or file a documentation bug requesting it.

+ +

Also, if the property is implemented by Firefox, you need to check that it is listed, and linked! in the correct Firefox for developers MDN page. The new CSS property is likely already listed in the HTML section, just be sure that its name links back to your newly created page.

+ +

Contact us

+ + diff --git a/files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html b/files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html new file mode 100644 index 0000000000..d0f017a0f1 --- /dev/null +++ b/files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html @@ -0,0 +1,50 @@ +--- +title: Anleitung zur Erstellung eines MDN Profils +slug: MDN/Contribute/Howto/ERstellung_eines_MDN_Profils +tags: + - Anfänger + - Einführung +translation_of: MDN/Contribute/Howto/Create_an_MDN_account +--- +
{{MDNSidebar}}

Um Änderungen an den Inhalten von MDN vornehmen zu können, brauchst du ein MDN - Profil (egal ob du Seiten ändern oder eine Demo hinzufügen willst). Aber keine Angst, du brauchst kein Profil wenn du in MDN lesen oder suchen  willst.

+ +

Diese kleine Anleitung wird dir helfen, dein MDN Profil selbst zu erstellen:

+ +

Warum braucht MDN deine eMail adresse ?   Die eMail Adresse wird verwendet um den Account wieder herzustellen

+ +
Warum braucht MDN deine E-Mail-Adresse ?
+
+Die E-Mail-Adresse wird verwendet, um den Account wiederherzustellen.                                                                                                                          Zusätzlich hast du die Möglichkeit, Benachrichtigungen zu erhalten (wie z.B. wenn sich bestimmte Seiten ändern). Wenn Du z.B. die Option "Teilnehmen am Beta Test Team" gewählt hast, erhälst du E-Mails über neue Funktionen, die getestet werden können.
+
+Deine E-Mail-Adresse wird in MDN nie und ausschließlich in Übereinstimmung mit unserer Datenschutzrichtlinie benutzt.
+ +
    +
  1. In der rechten oberen Ecke jeder Seite befindet sich die Schaltfläche Anmelden mit. Gehe mit Deinem Mausezeiger dorthin und du bekommst eine Liste von Anmeldediensten für MDN angezeigt.
    2. +
  2. Wähle einen Dienst z.B. Anmelden mit Persona. Es öffnet sich ein neues Fenster mit dem Persona Login.
    3. +
  3. Gib Deine E-Mail-Adresse ein, die Du für Dein neues Profil benutzen willst und drücke auf Weiter.
    4. +
  4. Der nächste Punkt ist anhängig davon, ob Du E-Mail-Adresse bereits für Persona benutzt. +
      +
    • Falls Sie bereits Persona nutzen, wird nach Ihrem existierenden Passwort gefragt. Geben Sie es ein und klicken Sie auf Fertig.
      • +
    • Falls dies nicht der Fall ist, wird Persona Sie darum bitten, ein neues Password zu erstellen. +
        +
      1. Geben Sie ihr Passwort zweimal ein und drücken Sie auf Fertig.
        2. +
      2. Überprüfen Sie ihren E-Mail Nachrichtenkorb auf eine Nachricht von no-reply@persona.org; Falls Sie die Nachricht nicht erhalten, kontrollieren Sie bitte ihren Spam-Filter.
        3. +
      3. Bestätigen Sie den Registrationslink in der Nachricht . Ihr Persona Profil wurde erstellt.
        4. +
      4. Wechseln Sie wieder zu dem Tab, oder Fenster, indem Sie mit der Registrierung bei MDN begannen.
        5. +
      +
      • +
    +
    5. +
  5. Sobald Sie sich bei Persona authentifiziert haben. öffnet sich die Neues Profil Seite von MDN.
    6. +
  6. Geben Sie einen Nutzernamen ein, um sich mit Ihren Profil zu verknüpfen und drücken Sie auf Neues Profil erstellen.
    7. +
+ +

Das war's! Sie haben jetzt einen MDN Account und könne sofort Seiten bearbeiten oder mit Tags versehen, oder Demos einreichen!

+ +

Auf jeder MDN Seite können Sie auf Ihren Namen klicken um ihr öffentliches Profil zu sehen. Dort können Sie auf "Bearbeiten" klicken um Ihr Profil zu ändern oder zu erweitern. Auch können Sie etwas über Ihre Intressen teilen, einen Twitter Account oder Blog hinzufügen, und so weiter.

+ +
+

Hinweis: Nutzernamen können keine Leerzeichen oder das "@" Symbol beinhalten. Bedenken Sie bitte, dass ihr Nutzername für die Öffentlichkeit sichtbar ist, um festzustellen, was sie schon alles geleistet haben!

+
+ +

 

diff --git a/files/de/mdn/contribute/howto/index.html b/files/de/mdn/contribute/howto/index.html new file mode 100644 index 0000000000..9b2c82cf9f --- /dev/null +++ b/files/de/mdn/contribute/howto/index.html @@ -0,0 +1,13 @@ +--- +title: How-to Leitfäden +slug: MDN/Contribute/Howto +tags: + - Documentation + - Landing + - MDN + - NeedsTranslation + - TopicStub +translation_of: MDN/Contribute/Howto +--- +
{{MDNSidebar}}

Diese Artikel bieten Schritt-für-Schritt-Anleitungen zum Erreichuen bestimmter Zielsetzungen, wenn Sie zu MDN beitragen.

+

{{LandingPageListSubpages}}

diff --git "a/files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" "b/files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" new file mode 100644 index 0000000000..42a1d25435 --- /dev/null +++ "b/files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" @@ -0,0 +1,81 @@ +--- +title: Wie man JavaScript bezogene Seiten mit Schlagworten versieht +slug: MDN/Contribute/Howto/Schlagwörter_für_JavaScript_Seiten +translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages +--- +
{{MDNSidebar}}

Schlagwörter sind Metadaten, welche helfen den Inhalt einer Seite zusammenzufassen um unteranderem die Suche zu verbessern.

+ + + + + + + + + + + + + + + + +
Wo muss es gemacht werden?Auf bestimmten JavaScript bezogenen Seiten, welche keine Schlagwörter haben
Was muss du wissen um die Aufgabe zu erledigen? +
    +
  • JavaScript Grundkenntnisse, z.B. was eine Methode oder ein Attribut ist.
    • +
+
Welche Schritte müssen gemacht werden? +
    +
  1. Such dir eine Seite aus, welche du auf der oben verlinkten Liste findest.
    2. +
  2. Klicke auf den Artikel-Link um die Seite zu öffnen.
    3. +
  3. Sobald die Seite geladen ist kannst du auf den BEARBEITEN-Button oben rechts klicken, welcher den MDN-Editor öffnet.
    4. +
  4. Es sollte mindestens das Schlagwort JavaScript eingefügt werden. Folgend findest du weitere mögliche Schlagwörter die hinzugefügt werden können: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SchlagwortWann es verwendet werden sollte
    MethodMethoden
    PropertyAttribute
    prototypePrototypen
    Objekttypen NameMethoden eines Objektes z.B.: String.fromCharCode sollte das Schlagwort "String" haben
    ECMAScript6 and ExperimentalFunktionen welche in einer neuen ECMAScript Version hinzugefügt wurden
    DeprecatedVeraltete Funktionen (Deren Verwendung nicht mehr empfohlen wird, dennoch noch möglich ist)
    ObsoleteObsolete Funktionen (Welche nicht mehr von neueren Browsern unterstützt werden)
    othersSiehe MDN Leitfaden zur sachgemäßen Seitenkennzeichnung für andere mögliche Schlagwörter
    +
    5. +
  5. Speichere mit einem kurzen Kommentar.
    6. +
  6. Du bist fertig!
    7. +
+
+ +

 

diff --git a/files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html b/files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html new file mode 100644 index 0000000000..8c30eb2dcb --- /dev/null +++ b/files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html @@ -0,0 +1,54 @@ +--- +title: Wie erstelle ich eine Zusammenfassung für eine Seite +slug: MDN/Contribute/Howto/Set_the_summary_for_a_page +tags: + - Beginner + - Guide +translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page +--- +
{{MDNSidebar}}

Sie können die Zusammenfassung einer Seite am MDN definieren, diese wird in verschiedenen Arten verwendet, einschließlich in Suchmaschinenergebnissen, auf anderen MDN Seiten wie als Themeneinführung, und in Tooltipps. Es sollte ein Text sein, welcher in Zusammenhang mit der Seite, als auch alleine Sinn macht.

+ +

Eine Zusammenfassung kann explizit für eine Seite definiert werden. Wenn sie nicht explizit definiert wird, so wird oft der erste Satz oder ähnliche benutzt, welche nicht immer die besten für diese Verwendung sind.

+ + + + + + + + + + + + + + + + + + + + +
Was ist die Aufgabe?Markieren Sie den Text in einer Seite, welcher als Zusammenfassung, auch in anderen Zusammenhängen,  verwendet werden soll; diese Aufgabe kann das Schreiben eines entsprechenden Texts beinhalten.
Wo muss es gemacht werden?Auf Seiten, welche keine oder keine gute Zusammenfassung haben.
Was müssen Sie wissen, um die Aufgabe zu erledigen?Fähigkeit den MDN Editor zu benutzen; gute Schreibkompetenz in Deutsch; genug Vertrautheit mit der Seite um eine gute Zusammenfassung schreiben zu können.
Welche Schritte sind zu unternehmen? +
    +
  1. Wählen Sie eine Seite aus, für welche die Zusammenfassung erstellt werden soll: +
      +
    1. Wählen Sie auf der MDN Dokumentationsstatus Seite unter der Kategorie Sections ein Thema über welches Sie etwas wissen (zum Beispiel: HTML).
      2. +
    2. Klicken Sie Pages auf der Dokumentationsstatus Seite, um eine Übersicht über alle Seiten in diesem Abschnitt zu bekommen; in der linken Spalte sehen Sie Links zu den Seiten, und in der Rechten Spalte sehen Sie die Schlüsselwörter und die Zusammenfassung.
      3. +
    3. Wählen Sie eine Seite aus, welche keine oder nur eine schlechte Zusammenfassung besitzt.
      4. +
    4. Klicken Sie auf den Link um auf die Seite zu gelangen.
      5. +
    +
    2. +
  2. Klicken Sie auf Edit um die Seite im MDN Editor zu öffnen.
    3. +
  3. Suchen Sie einen oder zwei Sätze, welche auch außerhalb der Seite als Zusammenfassung funktionieren. Wenn benötigt, bearbeiten Sie den existierenden Inhalt indem sie Sätze erzeugen, oder so verändern, dass sie eine gute Zusammenfassung ergeben.
    4. +
  4. Wählen Sie den Text der Zusammenfassung aus.
    5. +
  5. Wählen Sie im Styles Widget in der Editor Toolbar SEO Summary aus. (Im Seitenquelltext erzeugt das ein {{HTMLElement("span")}} Element mit class="seoSummary" um den ausgewählten Text.)
    6. +
  6. Speichern Sie Ihre Änderungen mit einem Revision Comment wie "Seitenzusammenfassung erstellt."
    7. +
+
+ +

 

+ +

 

+ +

 

diff --git a/files/de/mdn/contribute/howto/tag/index.html b/files/de/mdn/contribute/howto/tag/index.html new file mode 100644 index 0000000000..7fd597e80f --- /dev/null +++ b/files/de/mdn/contribute/howto/tag/index.html @@ -0,0 +1,429 @@ +--- +title: Leitfaden zum Setzen von Schlagwörtern +slug: MDN/Contribute/Howto/Tag +tags: + - Beginner + - Contribute + - Guide + - Howto + - Intro + - MDN Meta + - Tutorial +translation_of: MDN/Contribute/Howto/Tag +--- +
{{MDNSidebar}}
+ +

Artikel-Schlagwörter sind ein wichtiges Hilfsmittel, es Besuchern zu ermöglichen, hilfreichen Inhalt zu finden. Jede Seite sollte im Normalfall mehrere Schlagwörter enthalten. Diese Seite erklärt die beste Art Seiten zu markieren, so dass Leser Informationen finden und wir selbst Ordnung bewahren können.

+ +

Um zur Hilfe für die Oberfläche zur Bearbeitung von Schlagwörtern zu gelangen, rufen Sie bitte den Link tagging section in unserem Editor-Handbuch auf.

+ +

Bitte nutzen Sie die Schlagwörter sachgemäß, wie folgend beschrieben. Wenn Sie dies nicht tun, sind unsere automatischen Werkzeuge nicht in der Lage, Listen des Inhalts, der Einstiegsseiten und querverweisenden Artikel zu generieren.

+ +

Schlagwort-Verwendung im MDN

+ +

Auf MDN werden Schlagwörter auf verschiedene Weisen verwendet.

+ +
+
Dokument-Kategorisierung
+
Um welchen Dokumenten-Typ handelt es sich? Ist es eine Referenz? Ein Tutorial? Eine Eine Einstiegsseite zu einem Thema? Unsere Besucher können diese Schlagwörter verwenden, um Suchen zu filtern, deshalb sind sie sehr wichtig!
+
Topic-Identifizierung
+
Worum geht es in dem Artikel? Ist er über eine API? Das DOM? Grafik? Auch diese Schlagwörter sind sehr wichtig, weil sie als Suchfilter verwendet werden können.
+
API-Identifizierung
+
Referenzseiten über eine API müssen die spezifische Komponente der API, die auf Ihnen dokumentiert wird, bezeichnen (das heißt: zu welchem Interface sie gehört und welche Eigenschaft oder Methode sie umfasst, falls zutreffend).
+
Technologie-Status
+
Welchen Status hat die beschriebene Technologie? Entspricht sie einem Standard oder nicht? Wird sie nicht mehr verwendet oder ist veraltet? Ist sie experimentell?
+
Skill-Level
+
Für Tutorials und Anleitungen - Wie weit fortgeschritten ist das Material, das im Artikel behandelt wird?
+
Dokument-Metadaten
+
Die Autoren-Gemeinschaft verwendet Schlagwörter, um nachvollziehen zu können, welche Seiten welcher Art von Arbeit bedürfen.
+
+ +

Handbuch zu Schlagwort-Typen

+ +

Hier ist eine Kurzanleitung zu den verschiedenen Schlagwort-Typen und ihre konkreten Werte.

+ +

Kategorie

+ +

Wenn Sie einen Artikel mit einem Schlagwörter aus diesen Kategorien versehen, unterstützen sie die automatischen Werkzeuge dabei, genauer Einstiegsseiten, Inhaltsverzeichnise usw. zu generieren.

+ +

Wir verwenden die folgenden Kategorien als Standard-Schlagwörter:

+ +
+
{{Tag("Intro")}}
+
Der Artikel stellt Einführungs-Material zu einem Thema zur Verfügung. Theoretisch sollte jeder Technologie-Bereich nur ein "Intro" haben.
+
{{Tag("Featured")}}
+
Dieser Artikel ist ein äußerst wichtiger Artikel, der mittels einer speziellen Methode auf erreichte Seiten hinweist. Bitte achten Sie auf eine äußerst sparsame Anwendung. Es sollten max. drei oder weniger in den Dokumentations-Bereichen existieren (Dieses Schlagwort wird in der englischen Version dieser Seite nicht mehr beschrieben und ist möglicherweise nicht mehr aktuell).
+
{{Tag("Reference")}}
+
Der Artikel enthält Referenz-Material über ein API, ein Element, ein Attribut, ein Merkmal oder ähnliches.
+
{{Tag("Landing")}}
+
Diese Seite ist eine Einstiegsseite.
+
{{Tag("Guide")}}
+
Dieser Artikel ist eine Schritt-für-Schritt Anleitung oder ein Leitfaden.
+
{{Tag("Example")}}
+
Dieser Artikel ist eine reine Code-Beispielseite, oder enthält Code-Beispiele (das heißt, tatsächlich nützliche Code-Schnipsel, nicht einzeilige "Syntaxbeispiele").
+
+ +

Themen

+ +

Durch die Angabe des Themenbereiches können Sie helfen, bessere Suchergebnisse zu erzeugen (und damit auch Einstiegsseiten und sonstige Navigations-Hilfen).

+ +

Derzeit ist hier noch etwas Raum für Flexibilität, da wir noch neue Themenbereiche identifizieren. Wir versuchen allerdings, uns auf die Namen von APIs oder Technologien zu beschränken. Einige nützliche Bespiele:

+ + + +

Generell nützlich ist der Name eines Interfaces, wie auch weitere verwandte Seiten (wie z.B. bei Node, das viele verwandte Seiten für seine verschiedenen Eigenschaften und Methoden hat), oder der Name des übergeordneten Technologie-Typs. Eine Seite über WebGL könnten Sie zum Beispiel mit den Schlagwörtern Graphics und WebGL versehen, aber eine Seite über {{HTMLElement("canvas")}} könnte mit HTML, Element, Canvas, und Graphics gekennzeichnet werden.

+ +

Mozilla-spezifische Inhalte

+ +

Diese Schlagwörter werden nur für Mozilla-spezifische Inhalte verwendet:

+ + + +

API-Identifikation

+ +

In der API-Referenz sollte aus jedem Artikel hervorgehen, welchen Teil der API er abdeckt:

+ +
+
{{Tag("Interface")}}
+
Der Hauptartikel für ein Interface sollte dieses Schlagwort verwenden. Zum Beispiel: RTCPeerConnection.
+
{{Tag("Constructor")}}
+
Jedes Interface darf bis zu eine Seite haben, die mit "Constructor" gekennzeichnet ist. Dies ist der Konstruktor des Interface. Die Seite sollte den gleichen Namen haben wie das Interface, wie in RTCPeerConnection.RTCPeerConnection().
+
{{Tag("Property")}}
+
Jeder Artikel, der eine Eigenschaft von einem Interface beschreibt, benötigt dieses Schlagwort. Siehe zum Beispiel: RTCPeerConnection.connectionState().
+
{{Tag("Method")}}
+
Jeder Artikel, der eine Methode eines Interfaces dokumentiert, benötigt dieses Schlagwort. Siehe zum Beispiel: RTCPeerConnection.createOffer().
+
+ +

Weiterhin müssen Referenzseiten Interface, Eigenschaft und Methodennamen in ihrer Schlagwortliste enthalten. Einige Bespiele:

+ +
+
Das Interface RTCPeerConnection
+
Fügen Sie die Schlagwörter RTCPeerConnection zusammen mit den anderen relevanten Schlagwörtern ( Interface, WebRTC, WebRTC API, API, Reference, usw.) hinzu.
+
Die Methode RTCPeerConnection.createOffer()
+
Fügen Sie die Schlagwörter RTCPeerConnection und createOffer (Beachten Sie hierbei: keine Klammern in Schlagwörtern!) zusammen mit den anderen relevanten Schlagwörtern hinzu, wie Method, WebRTC, WebRTC API, API, Reference, usw. Erwägen Sie auch die Verwendung von Schlagwörtern wie Offer und SDP, die hier auch relevant sind.
+
Die Eigenschaft RTCPeerConnection.iceConnectionState
+
Fügen Sie die Schlagwörter RTCPeerConnection und iceConnectionState zusammen mit anderen relevanten Schlagwörtern hinzu, wie Property, WebRTC, WebRTC API, API und Reference. Erwägen sie auch, ICE hinzuzufügen.
+
+ +

Technologie-Status

+ +

Um dem Leser bei dem Verstehen, wie praktikabel eine Technologie ist, zu unterstützen, verwenden wir Schlagwörter, um Seiten mit dem Stand einer technischen Spezifikation zu markieren. Dies ist zwar nicht so detailliert, wie das erklären der Spezifikation und wie weit der Spezifikations-Prozess fortgeschritten ist (dafür gibt es die Spezifikations-Tabelle), aber es hilft dem Leser, mit einem kurzen Blick einzuschätzen, ob es eine gute Idee ist, die beschriebene Technologie zu verwenden.

+ +

Hier sind mögliche Belegungen für diese Schlagwörter:

+ +
+
{{Tag("Read-only")}}
+
Nutzen Sie dieses Schlagwort für Referenzseiten, die eine Eigenschaft oder ein Attribut beschreiben, das einen Nur-Lese-Status hat.
+
{{Tag("Non-standard")}}
+
Weist darauf hin, dass die auf der Seite beschriebene Technologie oder API nicht Teil eines Standards ist, unabhängig davon, ob es in den Browsern, die es implementieren, stabil funktioniert (wenn es nicht stabil sind, sollte die Seite mit Experimental gekennzeichnet werden). Wenn Sie dieses Schlagwort nicht verwenden, werden Ihre Leser davon ausgehen, dass die Technologie ein Standard ist. Die Kompatibilitäts-Tabelle auf der Seite sollte klarstellen, welche/-r Browser diese API oder Technologie unterstützen.
+
{{Tag("Deprecated")}}
+
Die Technologie oder die API auf der Seite ist in der Spezifikation als veraltet gekennzeichnet und es ist zu erwarten, dass sie irgendwann entfernt wird, jedoch ist sie im Allgemeinen in den aktuellen Versionen der Browser noch verfügbar.
+
{{Tag("Obsolete")}}
+
Die Technologie oder API gilt als veraltet und wurde aus allen, bzw. den meisten aktuellen Browsern entfernt (oder sie wird gerade aktiv entfernt).
+
{{Tag("Experimental")}}
+
Die Technologie ist nicht standardisiert und ist noch eine experimentelle Technologie oder API, die möglicherwiese zukünftig ein Standard werden könnte. Sie unterliegt zudem der stetigen Veränderungen in der Browserengine, die sie implementiert (typischerweise ist dies nur eine). Wenn die Technologie nicht Teil einer Spezifikation ist (auch, falls sie Teil eines Entwurfs derselben ist), so sollte sie außerdem das Schlagwort Non-standard bekommen.
+
{{Tag("Needs Privileges")}}
+
Die API benötigt privilegierten Zugriff zu dem Gerät, auf dem der Code läuft.
+
{{Tag("Certified Only")}}
+
Die API funktioniert ausschließlich mit zertifiziertem Code.
+
+ +

Die Verwendung dieser Schlagwörter ist kein Grund dafür, dass Sie die Kompatibilitätstabelle in Ihrem Artikel weglassen können! Die sollte immer vorhanden sein.

+ +

Fertigkeitsstand

+ +

Nutzen Sie die Fertigkeitsstand-Schlagwörter nur für Guides und Tutorials (also Seiten, die mit dem Schlagwort: Guide gekennzeichnet wurden). Sie sollen den Benutzern dabei helfen, basierend darauf, wie gut sie eine Technologie kennen, das richtige Tutorial auszuwählen. Hierfür gibt es drei Schlagwörter:

+ +
+
{{Tag("Beginner")}}
+
Artikel für Anfänger mit dem Zweck der Einführung in eine Technologie, die sie noch nie angewendet haben bzw. mit der sie nur wenig vertraut sind.
+
{{Tag("Intermediate")}}
+
Artikel für Anwender, die zwar schon begonnen haben, die Technologie zu benutzen, jedoch keine Experten sind.
+
{{Tag("Advanced")}}
+
Artikel mit dem Ziel, die Fähigkeiten der Technologien und des Lesers vollständig auszuschöpfen.
+
+ +

Dokument-Metadaten

+ +

Die Autoren-Gemeinschaft verwendet Schlagwörter, um Artikel entsprechend der Art der Arbeit, die gemacht werden muss, zu kennzeichnen. Hier ist eine Liste der Schlagwörter, die wir am häufigsten dafür benutzen:

+ +
+
{{Tag("Draft")}}
+
Der Artikel ist noch nicht vollständig und wird zumindest theoretisch noch aktiv überarbeitet (auch wenn es möglich ist, dass man ihn vergessen hat). Versuchen Sie, die letzten Beitragenden zu kontaktieren, bevor Sie Veränderungen vornehmen, um mögliche Inhaltskollisionen zu vermeiden.
+
{{Tag("junk")}}
+
Beitrag enthält wertloses Zeug - sollte entfernt werden (Dieses Schlagwort wird in der englischen Version dieser Seite nicht mehr beschrieben und ist möglicherweise nicht mehr aktuell).
+
{{Tag("NeedsCompatTable")}}
+
Der Artikel benötigt eine Tabelle, welche die Kompatibilität eines Features mit verschiedenen Browsern aufzeigt. Siehe hier für die Anleitung zum Beitragen der Browser-Kompatiblität.
+
{{Tag("NeedsContent")}}
+
Der Artikel ist ein Kurzeintrag oder es fehlen auf eine andere Art und Weise Informationen. Das bedeutet, dass jemand den Inhalt überarbeiten, mehr Details hinzufügen und/oder den Artikel zu Ende schreiben sollte.
+
{{Tag("NeedsExample")}}
+
Der Artikel benötigt ein oder mehrere Beispiele, um den Inhalt zu illustrieren. Solche Beispiele sollten das live sample system benutzen.
+
{{Tag("NeedsLiveSamples")}}
+
In diesem Artikel bit es ein oder mehrere Beispiele, die mittels live sample system erneuert werden müssen.
+
{{Tag("NeedsSpecTable")}}
+
Der Artikel benötigt eine Tabelle, welche das bzw. die Dokument/-e enthält, in dem/denen das Feature definiert wurde.
+
{{Tag("NeedsUpdate")}}
+
Der Inhalt ist veraltet und muss aktualisiert werden.
+
{{Tag("l10n:exclude")}}
+
Der Inhalt ist es nicht wirklich wert, übersetzt zu werden und wird nicht auf Übersetzungs-Status-Seiten erscheinen.
+
{{Tag("l10n:priority")}}
+
Der Inhalt ist wichtig und sollte für MDN-Übersetzer als priorisiert markiert sein. Er wird in einer extra Prioritäts-Tabelle auf Lokalisierungs-Status-Seiten erscheinen.
+
+ +

Web Literacy Map

+ +

(Dieser Abschnitt ist in der Englischen Version dieser Seite nicht mehr vorhanden und möglicherweise nicht mehr aktuell) Das WebMaker Projekt, siehe Web Literacy Map, hat eine Reihe von Schlagwörtern definiert, um die verschiedenen und empfohlenen Fähigkeiten zu definieren, die ein besseres Lesen, Schreiben und die Teilnahme am Web ermöglichen. Wir benutzen sie auf MDN, um unseren Anwendern die besten Resourcen zu finden, welche ihren Ansprüchen genügen:

+ +
+
{{Tag("Navigation")}}
+
Der Beitrag liefert Informationen darüber wie man das Web durchsuchen kann.
+
{{Tag("WebMechanics")}}
+
Der Beitrag liefert Informationen darüber wie das Web organisiert ist und wie es funktioniert.
+
{{Tag("Search")}}
+
Der Beitrag zeigt die Möglichkeiten auf, wo Informationen, Personen und Resourcen mittels des des Webs zu finden sind.
+
{{Tag("Credibility")}}
+
Der Artikel liefert Informationen darüber wie kritisch zu bewertende Informationen sind, die auf dem Web gefunden wurden.
+
{{Tag("Security")}}
+
Der Artikel liefert Informationen wie man Systeme, Identitäten und Inhalt sicher aufbewahrt.
+
{{Tag("Composing")}}
+
Der Artikel liefert Informationen wie Inhalt für das Web kreiert und sichert.
+
{{Tag("Remixing")}}
+
Der Artikel liefert Informationen wie man existierende Web-Resourcen nutzt, um neue Inhalte zu erstellen.
+
{{Tag("DesignAccessibility")}}
+
Der Artikel liefert Informationen darüber, wie eine effektive und universelle Kommunikation mittels Nutzung der Web-Resourcen zustande gebracht werden kann.
+
{{Tag("CodingScripting")}}
+
Der Artikel liefert Informationen wie interaktive Kodierung und/oderErfahrungen auf dem Web erstellt werden können.
+
{{Tag("infrastructure")}}
+
Der Artikel liefert Informationen, die das Verständnis der Internet-Technik aufzeigen.
+
{{Tag("Sharing")}}
+
Der Artikel zeigt auf, wie man zusammen mit anderen Teilnehmern Resourcen kreiert.
+
{{Tag("Collaborating")}}
+
Der Artikel liefert Informationen wie man mit an deren zusammenarbeiten kann.
+
{{Tag("Community")}}
+
Der Artikel liefert Informationen wie man in Web-Communities eingebunden werden kann und zeigt deren Praktiken auf.
+
{{Tag("Privacy")}}
+
Der Artikel liefert Informationen über Konsequenzen, wenn Daten online ausgetauscht werden.
+
{{Tag("OpenPracticies")}}
+
Der Artikel liefert Informationen wie geholfen werden kann, das Web universell zugänglich zu machen.
+
+ +

Zusammenfassung

+ +

Für jede Seite fügen Sie nun verscheidene Schlagwort-Typen hinzu, zum Beispiel:

+ +
+
Eine Anleitung über WebGL für Anfänger:
+
{{Tag("WebGL")}}, {{Tag("Graphics")}}, {{Tag("Guide")}}, {{Tag("Beginner")}}
+
Referenz-Seite für das {{HTMLElement("canvas")}} Element
+
{{Tag("Canvas")}}, {{Tag("HTML")}}, {{Tag("Element")}}, {{Tag("Graphics")}}, {{Tag("Reference")}}
+
Seite für Firefox OS Entwickler-Werkzeuge
+
{{Tag("Tools")}}, {{Tag("Firefox OS")}}, {{Tag("Landing")}}
+
+ +

Schlagwörter und Suchfilter

+ +

Suchfilter funktionieren nicht richtig, außer wir verwenden die Schlagwörter der MDN-Seiten korrekt. Hier ist eine Tabelle mit Suchfiltern und den Schlagwörtern, die sie benutzen. (Diese Tabelle ist möglicherweise nicht aktuell, siehe auch englische Version)

+ +
+

Note: Falls mehrere Tags unter "Tag Name" gelistet sind, bedeutet das, dass einer oder mehrere dieser Tags benötigt werden, damit der Artikel gefunden wird.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Filter-GruppeSuchfilter NameSchlagwörter
TopicOpen Web Apps{{Tag("Apps")}}
HTML{{Tag("HTML")}}
CSS{{Tag("CSS")}}
JavaScript{{Tag("JavaScript")}}
APIs and DOM{{Tag("API")}}
Canvas{{Tag("Canvas")}}
SVG{{Tag("SVG")}}
MathML{{Tag("MathML")}}
WebGL{{Tag("WebGL")}}
XUL{{Tag("XUL")}}
Marketplace{{Tag("Marketplace")}}
Firefox{{Tag("Firefox")}}
Firefox for Android{{Tag("Firefox Mobile")}}
Firefox for Desktop{{Tag("Firefox Desktop")}}
Firefox OS{{Tag("Firefox OS")}}
Mobile{{Tag("Mobile")}}
Web Development{{Tag("Web Development")}}
Add-ons & Extensions{{Tag("Add-ons ")}}|| {{Tag("Extensions")}} || {{Tag("Plugins")}} || {{Tag("Themes")}}
Games{{Tag("Games")}}
Skill levelI'm an Expert{{Tag("Advanced")}}
Intermediate{{Tag("Intermediate")}}
I'm Learning{{Tag("Beginner")}}
Document typeDocsThis will restrict the search to docs content, leaving out Hacks and other MDN content.
DemosThis will include Demo Studio content in the search results.
Tools{{Tag("Tools")}}
Code Samples{{Tag("Example")}}
How-To & Tutorial{{Tag("Guide")}}
Developer ProfilesThis will include developer profiles from the MDN site in the search results.
External ResourcesThis is something the dev team will need to figure out.
+ +

Schlagwörter-Probleme, die Sie beheben können

+ +

Es gibt verschiene Typen von Problemen mit Schlagwörtern, die Sie beheben können.

+ +
+
Keine Schlagwörter
+
im Allgemeinen sollten alle Artikel mindestens mit einem category und einem topic Schlagwort versehen sein. Meistens sind auch andere Schlagwörter sinnvoll, aber wenn Sie uns helfen können, diese minimale Kennzeichnung mit Schlagwörtern auf allen Seiten sicherzustellen, sind sie ein Dokumentationsheld!
+
Schlagwörter, die nicht unseren Schlagwort-Standards entsprechen
+
Bitte beseitigen sie in alle Probleme auf Seiten, deren Schlagwörter nicht den Standars auf dieser Seite folgen. Beachten Sie, dass Sie gelegentlich einige lokalisierte Schlagwörter auf Englischen Seiten sehen werden (wie Référence). Dies ist aufgrund eines Bugs in Kuma passiert, was dazu führte, das einige Schlagwörter wieder auftauchten, auch wenn sie bereits gelöscht waren. Dieser Bug wurde seitdem behoben, sodass sämtliche verbliebene lokalisierte Schlagwörter (auf den englischen Seiten) bereinigt werden können, wenn sie gesichtet werden.
+
Falsch verwendete Schlagwörter
+
Wenn Sie sich einen Artikel über HTML ansehen, der mit dem Schlagwort "JavaScript" versehen ist, dann ist das wahrscheinlich falsch! Genauso ist es, wenn ein Artikel Mozilla-interne Dinge beschreibt, aber mit einem "Web" Schlagwort versehen ist. Das ist vermutlich auch falsch. Entfernen Sie diese Schlagwörter und fügen Sie die richtigen hinzu, falls sie noch nicht vorhanden sind. Bitte korrigieren Sie auch falsch geschriebene Schlagwörter (z.B. würde "Javascript" immer noch funktionieren, da Schlagwörter keine Groß- und Kleinschreibung berücksichtigen, aber lassen Sie uns nicht nachlässig sein!).
+
Fehlende Schlagwörter
+
Wenn ein Artikel ein paar, aber noch nicht alle Schlagwörter hat, die er benötigt, fügen Sie ruhig mehr hinzu. Zum Beispiel, wenn eine JavaScript-Referenzseite (korrekterweise) mit dem Schlagwort JavaScript versehen ist, aber keinem sonst, fügen Sie gerne das Schlagwort "Reference" oder einen anderes, passendes Kategorie-Schlagwort hinzu!
+
Schlagwort-Spam
+
Dieses heimtückische Biest ist das abstoßendste aller Schlagwort-Probleme: irgendein Web-Ungeziefer hat seine Häufchen in den Schlagwörtern hinterlassen (wie zum Beispiel "Free warez!" oder "Hey ich war auf deiner Seite unterwegs und wollte fragen ob du mir helfen kannst mein Flashplayer stürzt dauernd ab"). Wir müssen solche Schlagwörter sofort löschen! Sie sind unschön, es wird schwer, sie loszuwerden, wenn wir sie zu lange rumlungern lassen und sie sind schrecklich für {{Glossary("SEO")}}.
+
+ +

Wenn Sie eines (oder mehrere) dieser Probleme bemerken, melden Sie sich bei MDN an und klicken Sie auf "Bearbeiten" oben rechts am MDN-Fenster. Nachdem der Editor geladen ist, scrollen Sie nach unten zum Ende der Seite. Dort finden Sie die Schlagwort-Box. Für mehr Details zur Schlagwort-Oberfläche besuchen Sie bitte "The tags box" im MDN-Editor-Leitfaden.

diff --git a/files/de/mdn/contribute/index.html b/files/de/mdn/contribute/index.html new file mode 100644 index 0000000000..9859a888b0 --- /dev/null +++ b/files/de/mdn/contribute/index.html @@ -0,0 +1,91 @@ +--- +title: Beitragen zu MDN +slug: MDN/Contribute +tags: + - Anleitung + - Dokumentation + - Einstieg + - MDC Projekt + - MDN +translation_of: MDN/Contribute +--- +
{{MDNSidebar}}

Willkommen! Durch das Betreten dieser Seite haben Sie bereits den ersten Schritt getan, um bei MDN mitzuwirken. Hier finden Sie Anleitungen zu allen Möglichkeiten des Mitwirkens bei MDN, wie etwa Style Guides, Leitfäden zur Benutzung unseres Editors und verschiedener Tools und vieles mehr.

+
+
+

Leitfäden für Helfer

+
+
+ Erste Schritte
+
+ Eine Kurzanleitung für Ihren ersten Beitrag.
+
+ Leitfaden für Inhalte und Styles
+
+ Im Leitfaden für Inhalte und Styles auf MDN erfahren Sie Details zu Schreibstil, Seitenlayout und Styles von Inhalten, so dass die von Ihnen verfassten Inhalte zu den restlichen Inhalten auf MDN passen.
+
+ Autoren Anleitung
+
+ Eine vollständige Anleitung zur Verwendung des Editors von MDN.
+
+ Artikel überprüfen
+
+ Ein Leitfaden zur Durchführung von technischen und redaktionellen Überprüfungen des Inhalts der Beiträge. So helfen Sie sicherzustellen, dass alle Inhalte auf MDN so nützlich und lesbar wie möglich sind!
+
+ Terminologie und Konventionen
+
+ Unser Handbuch über Terminologie und Konventionen stellt Informationen bereit, die Ihnen helfen, das korrekte Fachvokabular in Ihren Beiträgen zu verwenden.
+
+ Mit der MDN Community zusammenarbeiten
+
+ Ein Leitfaden zur Zusammenarbeit mit unserer Community, zum Auffinden von Hilfe und wie man mit den Leuten Kontakt aufnimmt, die Antworten auf die Fragen haben, die während Ihren Beiträgen zu MDN auftauchen.
+
+ Häufig gestellte Fragen
+
+ Tipps und Antworten zu den häufigsten Fragen über Beiträge zu MDN.
+
+
+
+ Zu Kuma beitragen
+
+ Eine Anleitung zu Beiträgen zum Kuma Projekt. Kuma ist der Name der Plattform, welche die MDN Webseiten unterstützt.
+
+
+
+

How to...

+

Unsere how-to Leitfäden stellen Schritt-für-Schritt-Anleitungen bereit, die Ihnen bei der Bewältigung spezieller Aufgaben während des Verfassens von Beiträgen für MDN behilflich sind.

+
+
+ Wie man eine CSS Eigenschaft dokumentiert
+
+ Eine Anleitung zum Dokumentieren von CSS Eigenschaften. Alle Dokumente über CSS Eigenschaften sollten dem in diesem Artikel beschriebenen Stil und Layout entsprechen.
+
+ Wie man ein HTML Element dokumentiert
+
+ Diese Anleitung zur Dokumentation von HTML Elementen gewährleistet, dass von Ihnen verfasste Dokumente zu anderen auf MDN passen.
+
+ Wie man Seiten richtig mit Schlagwörtern auszeichnet
+
+ Diese Anleitung zur Verschlagwortung von Seiten informiert über unsere Standards bezüglich Schlagwörtern (Tags), einschließlich Listen mit Tags, die eine Standardbedeutung auf MDN haben. Indem Sie dieser Anleitung folgen wird gewährleistet, dass Ihre Inhalte korrekt kategorisiert und leichter durchsuchbar sind und dass unser Suchfiltermechanismus mit Ihren Artikeln richtig funktioniert.
+
+ Wie man Spezifikationen deutet
+
+ Diese Anleitung hilft Ihnen, Standard-Web-Spezifikationen richtig zu verstehen. In der Lage zu sein, diese zu lesen, kann eine Kunst sein, und zu wissen, wie es geht, wird Ihnen helfen, bessere Dokumentationen zu schreiben.
+
+

Lokalisierung

+
+
+ Führung zur Lokalisierung
+
+ Während dieser Führung lernen Sie, wie Sie Inhalte auf MDN lokalisieren.
+
+ Leitfaden zur Lokalisierung
+
+ Diese Anleitung bietet detaillierte Informationen über den Lokalisierungsprozess für Inhalte auf MDN.
+
+ Lokalisierungsprojekte
+
+ Finden Sie das Lokalisierungsprojekt für Ihre Sprache—oder, wenn es noch keines gibt, erfahren Sie, wie man ein neues startet!
+
+
+
+

 

diff --git a/files/de/mdn/contribute/localize/index.html b/files/de/mdn/contribute/localize/index.html new file mode 100644 index 0000000000..dcb1fcc13e --- /dev/null +++ b/files/de/mdn/contribute/localize/index.html @@ -0,0 +1,29 @@ +--- +title: Lokalisieren von MDN +slug: MDN/Contribute/Localize +tags: + - Documentation + - Localization + - MDN + - NeedsTranslation + - TopicStub +translation_of: MDN/Contribute/Localize +--- +
{{MDNSidebar}}

MDN wird von Menschen auf der ganzen Welt als Referenz und Anleitung für Web Technologien, wie auch für Internas von Firefox selbst, genutzt. Unsere Lokalisierungsgemeinschaften sind ein wichtiger Teil des Mozilla Projekts. Ihre Übersetzungs- und Lokalisierungsarbeit hilft Menschen auf der ganzen Welt, um für das offene Web zu entwickeln. Wenn Sie mehr über unsere Lokalisierungsteams erfahren möchten, einem Team beitreten oder sogar eine neue Lokalisierung beginnen möchten, ist dies der Ort, um damit zu beginnen.

+

{{LandingPageListSubpages}}

+

Lokalisierungstools

+

Es gibt einige nützliche Tools, die Sie bei Ihrer Übersetzungsarbeit nutzen werden:

+
+
+ Verbatim
+
+ Wird für die Übersetzung von Zeichenketten über verschiedene Mozilla Projekte hinweg genutzt, einschließlich der MDN Benutzeroberfläche (sowie der Firefox Benutzeroberfläche).
+
+ Transvision
+
+ Ein Werkzeug von Mozilla France, das Sie nach einer englischen Zeichenkette suchen lässt und als Ergebnis die verschiedenen Übersetzungen einer Sprache dazu liefert, die im gesamten Mozilla Code verwendet werden. Dieses Werkzeug eignet sich, um die bevorzugte Übersetzung eines Wortes oder eines Satzes zu finden.
+
+

Siehe

+ diff --git a/files/de/mdn/contribute/localize/translating_pages/index.html b/files/de/mdn/contribute/localize/translating_pages/index.html new file mode 100644 index 0000000000..796212f0ac --- /dev/null +++ b/files/de/mdn/contribute/localize/translating_pages/index.html @@ -0,0 +1,58 @@ +--- +title: MDN Seiten übersetzen +slug: MDN/Contribute/Localize/Translating_pages +tags: + - Anfänger + - Beginner + - Guide + - Lokalisation + - MDN + - Seite Übersetzen + - Übersetzung + - übersetzen +translation_of: MDN/Contribute/Localize/Translating_pages +--- +
{{MDNSidebar}}
+ +

Dieser Artikel ist eine grundlegende Anleitung für die Übersetzung von Inhalten auf MDN. Er beinhaltet sowohl die Grundlagen für Übersetzungsarbeit als auch Tipps für den richtigen Umgang mit den verschiedenen Arten von Inhalten.

+ +

Eine neue Übersetzung einer Seite starten

+ +

Befolgen Sie diese Schritte, wenn Sie eine Seite in Ihre Sprache übersetzen möchten:

+ +
    +
  1. Klicken Sie auf das Sprachen-Symbol ({{FontAwesomeIcon("icon-language")}}), um das Sprachen-Menü zu öffnen und wählen Sie Übersetzung hinzufügen. Daraufhin erscheint die Auswahlseite der verfügbaren Sprachen.
    2. +
  2. Wählen Sie die Sprache, in die Sie die Seite übersetzen möchten. Anschließend öffnet sich ein Editor, auf dessen linker Hälfte die originale Seite, auf der rechten die Vorschau der übersetzten Seite zu sehen ist.
    3. +
  3. Unter Beschreibung übersetzen können Sie den Titel und optional den Adressnamen (Slug) in die Zielsprache übersetzen. Der Adressname ist der letzte Teil der URL einer Seite (zum Beispiel: "Translating_pages" für diesen Artikel.) Manche Sprachcommunities übersetzen den Adressnamen nicht und übernehmen den Englischen. Vergleichen Sie dazu am besten andere Artikel in Ihrer Sprache, um die gängige Praxis zu ermitteln. Um mehr Platz für den Abschnitt Übersetzung in Deutsch zu erhalten, können Sie auf das Minus-Zeichen neben dem Abschnitt Beschreibung übersetzen klicken und ihn so ausblenden.
    4. +
  4. Übersetzen Sie den Inhalt der Seite unter Übersetzung in Deutsch.
    5. +
  5. Tragen Sie mindestens ein Schlagwort für die Seite ein.
    6. +
  6. Drücken Sie Änderungen speichern wenn Sie fertig sind.
    7. +
+ +
Hinweis: Die Benutzeroberfläche der "Artikel übersetzen"-Ansicht wird anfangs in Englisch angezeigt. Bei nachfolgenden Bearbeitungen eines bestimmten Artikels im Editor wird die Benutzeroberfläche in der jeweils passenden Sprache angezeigt, falls eine Lokalisierung für MDN in dieser Sprache verfügbar ist. Die MDN Benutzeroberfläche kann mit Pontoon lokalisiert werden. Konsultieren Sie dazu Lokalisierung mit Pontoon für Details zu dessen Benutzung.
+ +

Eine übersetzte Seite bearbeiten

+ + + +

Wenn die englische Version seit der letzten Aktualisierung der Übersetzung verändert wurde, wird in der Artikel-Übersetzen-Ansicht die Quellebene "diff" mit den Änderungen der englischen Version angezeigt. Dies hilft Ihnen, Aktualisierungen schneller durchzuführen.

+ +

Schlagwort-Übersetzungen

+ +

Es ist wichtig, dass jede Seite mit mindestens einem Schlagwort getaggt wird, auch wenn es sich um eine Übersetzung handelt.

+ +

Manche Tags werden von Suchfiltern oder als Konventionen zwischen Beitragserstellern benutzt. Diese Schlagwörter sollten nicht übersetzt werden. Lesen Sie hierzu die Tagging Standards, um diese Schlagwörter zu erkennen.
+ Sie dürfen gern übersetzte Schlagwörter erstellen, um Inhalte zu gruppieren, wenn sie nicht von einem Standard-Schlagwort abgedeckt werden.

+ +

Tipps für neue Übersetzer

+ +

Sie sind neu bei der Lokalisierung auf MDN? Dann sind hier ein paar Ratschläge:

+ + diff --git a/files/de/mdn/contribute/zu_tun_im_mdn/index.html b/files/de/mdn/contribute/zu_tun_im_mdn/index.html new file mode 100644 index 0000000000..9eeff3ffd6 --- /dev/null +++ b/files/de/mdn/contribute/zu_tun_im_mdn/index.html @@ -0,0 +1,27 @@ +--- +title: Was alles im MDN zu tun ist +slug: MDN/Contribute/zu_tun_im_MDN +tags: + - Anleitung + - Guide + - MDN +translation_of: MDN/Contribute/Getting_started +--- +
{{MDNSidebar}}

Du willst das MDN besser machen? Es gibt viele Wege, wie du helfen kannst: du kannst Tippfehler verbessern, neue Inhalte verfassen, du kannst sogar die Kuma Plattform verbessern, auf welcher diese Seite aufbaut. Der Artikel "Beitragen zu MDN" deckt alle Möglichkeiten ab, wobei und wie du uns helfen könntest. Unten findest du eine etwas spezifischere Liste an Aufgaben die erledigt werden müssen.

+ +

Es gibt viele Möglichkeiten für dich zu helfen. Hier ist eine Liste mit den verschiedenen Dingen, die noch getan werden müssen:

+ + + +

Für mehr Ideen wie du helfen kannst, sieh dir unsere How-to Leitfäden an. Du kannst auf dieser Seite kategorisierte Listen von Seiten finden, die deine Hilfe benötigen.

+ +

Zusätzlich kannst du eine Liste mit großen Projekten die demnächst gestartet werden auf dem Trello Board vom MDN Team finden. Dieses Board zeigt dir sowohl woran die MDN Autoren gerade arbeiten, als auch Projekte an denen vermutlich demnächst angefangen wird zu arbeiten. Dieser Artikel zeigt dir wie du dieses Board nutzen kannst.

diff --git a/files/de/mdn/guidelines/index.html b/files/de/mdn/guidelines/index.html new file mode 100644 index 0000000000..cbf0c6aa77 --- /dev/null +++ b/files/de/mdn/guidelines/index.html @@ -0,0 +1,14 @@ +--- +title: MDN content and style guides +slug: MDN/Guidelines +tags: + - Guidelines + - Landing + - MDN Meta +translation_of: MDN/Guidelines +--- +
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

These guides provide details on how MDN documentation should be written and formatted, as well as how our code samples and other content should be presented. By following these guides, you can ensure that the material you produce is clean and easy to use.

+ +

{{LandingPageListSubpages}}

diff --git a/files/de/mdn/guidelines/style_guide/index.html b/files/de/mdn/guidelines/style_guide/index.html new file mode 100644 index 0000000000..274d9d4f8c --- /dev/null +++ b/files/de/mdn/guidelines/style_guide/index.html @@ -0,0 +1,560 @@ +--- +title: MDN style guide +slug: MDN/Guidelines/Style_guide +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/de-DE/docs/MDN")}}
+ +

Um die Dokumentation in einer organisierten, standardisierten und leicht verständlichen Weise darzustellen, beschreibt der MDN Web Docs Style Guide, wie dieser Text organisiert, geschrieben, formatiert und gestaltet werden sollte. Das sind eher Richtlinien als strenge Regeln. Wir sind mehr an Inhalten als an der Formatierung interessiert, also fühlen Sie sich nicht verpflichtet, den Style Guide zu lernen, bevor Sie einen Beitrag leisten. Seien Sie jedoch nicht verärgert oder überrascht, wenn ein fleißiger Freiwilliger Ihre Arbeit später bearbeitet, um sie an diesen Leitfaden anzupassen.

+ +

Wenn Sie nach Spezifikationen suchen, wie eine bestimmte Art von Seite strukturiert sein sollte, lesen Sie den MDN page layout guide.

+ +

Die sprachlichen Aspekte dieses Leitfadens gelten in erster Linie für die englischsprachige Dokumentation. Andere Sprachen haben möglicherweise ihre eigenen Styleguides (und können diese gerne erstellen). Diese sollten als Unterseiten auf der Seite des Lokalisierungsteams veröffentlicht werden.

+ +

Stilstandards, die für Inhalte gelten, die für andere Sites als MDN geschrieben wurden, finden Sie im One Mozilla style guide.

+ +

Basics

+ +

The best place to start in any major publishing style guide is with some very basic text standards to help keep documentation consistent. The following sections outline some of these basics to help you.

+ +

Page titles

+ +

Page titles are used in search results and also used to structure the page hierarchy in the breadcrumb list at the top of the page. The page title (which is displayed at the top of the page and in the search results) can be different from the page "slug," which is the portion of the page's URL following "<locale>/docs/".

+ +

Title and heading capitalization

+ +

Page titles and section headings should use sentence-style capitalization (only capitalize the first word and proper nouns) rather than headline-style capitalization:

+ + + +

We have many older pages that were written before this style rule was established. Feel free to update them as needed if you like. We're gradually getting to them.

+ +

Choosing titles and slugs

+ +

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should generally just be a word or two.

+ +

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

+ +

Creating new subtrees

+ +

When you need to add a number of articles about a topic or topic area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using a number of macros we've created.

+ +

For example, consider the JavaScript guide, which is structured as follows:

+ + + +

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

+ +

Sections, paragraphs, and newlines

+ +

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}} macros.

+ +

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the Shift key while pressing Enter.

+ +

Don't create single subsections -- you don't subdivide a topic into one. It's either two subheadings or more or none at all. 

+ +

Don't have bumping heads, which are headings followed immediately by headings. Aside from looking horrible, it's helpful to readers if every heading has at least a brief intro after it to introduce the subsections beneath.

+ +

Text formatting and styles

+ +

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

+ +
Note: The "Note" style is used to call out important notes, like this one.
+ +
Warning: Similarly, the "Warning" style creates warning boxes like this.
+ +

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.

+ +

Code sample style and formatting

+ +

Tabs and line breaks

+ +

Use two spaces per tab in all code samples. Code should be indented cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

+ +
if (condition) {
+  /* handle the condition */
+} else {
+  /* handle the "else" case */
+}
+
+ +

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

+ +
if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
+       || class.YET_ANOTHER_CONDITION ) {
+  /* something */
+}
+
+var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
+                           .createInstance(Components.interfaces.nsIToolkitProfileService);
+
+ +

Inline code formatting

+ +

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names (this uses the {{HTMLElement("code")}} element). For example, "the frenchText() function".

+ +

Method names should be followed by a pair of parentheses: doSomethingUseful(). This helps to differentiate methods from other code terms.

+ +

Syntax highlighting

+ +

Screenshot of the "syntax highlighting" menu.Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the {{HTMLElement("code")}} element. Click the "pre" button in the toolbar to create the preformatted content box in which you'll then write your code. Then, with the text entry cursor inside the code box, select the appropriate language from the language list button to the right of the "pre" button, as seen in the screenshot to the right. The following example shows text with JavaScript formatting:

+ +
+
for (var i = 0, j = 9; i <= 9; i++, j--)
+  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);
+
+ +

If no appropriate transformation is available, use the pre tag without specifying a language ("No Highlight" in the language menu).

+ +
x = 42;
+ +

Styling HTML element references

+ +

There are various specific rules to follow when writing about HTML elements, in order to consistently describe the various components of elements, and to ensure that they're properly linked to detailed documentation.

+ +
+
Element names
+
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).
+
Attribute names
+
Use bold face.
+
Attribute definitions
+
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
+
Attribute values
+
Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. E.g.: When the type attribute of an <input> element is set to email or tel ...
+
Labeling attributes
+
Use labels like {{HTMLVersionInline(5)}} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.
+
+ +

Latin abbreviations

+ +

In notes and parentheses

+ + + +

In running text

+ + + +

Meanings and English equivalents of Latin abbreviations

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbbrevLatinEnglish
cf.confercompare
e.g.exempli gratiafor example
et al.et aliiand others
etc.et ceteraand so forth, and so on
i.e.id estthat is, in other words
N.B.nota benenote well
P.S.post scriptumpostscript
+ +
+

Note: Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another. And be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

+
+ +

Acronyms and abbreviations

+ +

Capitalization and periods

+ +

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

+ + + +

Expansion

+ +

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

+ + + +

Plurals of acronyms and abbreviations

+ +

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

+ + + +

Capitalization

+ +

Use standard English capitalization rules in body text, and capitalize "World Wide Web" and "Web".

+ +

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER."

+ +

Contractions

+ +

Use contractions (e.g. "don't", "can't", "shouldn't") if you prefer. We're not that formal!

+ +

Pluralization

+ +

Use English-style plurals, not the Latin- or Greek-influenced forms.

+ + + +

Hyphenation

+ +

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

+ + + +

Gender-neutral language

+ +

It is a good idea to use gender-neutral language in any kind of writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So for example, if you are talking about the actions of a specific man, usage of he/his would be fine, but if the subject is a person of either gender, he/his isn't really appropriate.
+
+ Let's take the following example:

+ +
+

A confirmation dialog appears, asking the user if he allows the web page to make use of his web cam.

+
+ +
+

A confirmation dialog appears, asking the user if she allows the web page to make use of her web cam.

+
+ +

Both versions in this case are gender-specific. This could be fixed by using gender-neutral pronouns:

+ +
+

A confirmation dialog appears, asking the user if they allow the web page to make use of their web cam.

+
+ +
+

Note: MDN allows the use of this very common syntax (which is controversial among usage authorities), in order to make up for the lack of a neutral gender in English. The use of the third-person plural as a neutral gender pronoun (that is, using "they," them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

+
+ +

You can use both genders:

+ +
+

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.

+
+ +

making the users plural:

+ +
+

A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.

+
+ +

The best solution, of course, is to rewrite and eliminate the pronouns completely:

+ +
+

A confirmation dialog appears, requesting the user's permission for web cam access.

+
+ +
+

A confirmation dialog box appears, which asks the user for permission to use the web cam.

+
+ +

The last way of dealing with the problem is arguably better, as it is not only grammatically more correct but removes some of the complexity associated with dealing with genders across different languages that may have wildly varying gender rules. This can make translation easier, both for readers reading English, then translating it into their own language as they read, and for localizers translating articles into their own language.

+ +

Numbers and numerals

+ +

Dates

+ +

For dates (not including dates in code samples) use the format "January 1, 1990".

+ + + +

Alternately, you can use the YYYY/MM/DD format.

+ + + +

Decades

+ +

For decades, use the format "1990s". Don't use an apostrophe.

+ + + +

Plurals of numerals

+ +

For plurals of numerals add "s". Don't use an apostrophe.

+ + + +

Commas

+ +

In running text, use commas only in five-digit and larger numbers.

+ + + +

Punctuation

+ +

Serial comma

+ +

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

+ + + +
+

Note: This is in contrast to the One Mozilla style guide, which specifies that the serial comma is not to be used. MDN is an exception to this rule.

+
+ +

Spelling

+ +

For words with variant spellings, always use the first entry at Answers.com. Do not use variant spellings.

+ + + +

Terminology

+ +

Obsolete vs. deprecated

+ +

It's important to be clear on the difference between the terms obsolete and deprecated.

+ +
+
Obsolete:
+
On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.
+
Deprecated:
+
On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.
+
+ +

HTML elements

+ +

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style. Also, at least the first time you reference a given element in a section should use the {{TemplateLink("HTMLElement")}} macro, to create a link to the documentation for the element (unless you're writing within that element's reference document page).

+ + + +

User interface actions

+ +

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

+ + + +

Voice

+ +

While the active voice is generally preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

+ +

Wiki markup and usage

+ + + +

To automatically create a link to a Bugzilla bug, use this template:

+ +
\{{Bug(322603)}}
+
+ +

This results in:

+ +

{{Bug(322603)}}

+ +

For WebKit bugs, you can use this template:

+ +
\{{Webkitbug("322603")}}
+
+ +

This results in:

+ +

{{Webkitbug("322603")}}

+ +

Page tags

+ +

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

+ +

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

+ +

Screenshot of the UX for adding and removing tags on MDN

+ +

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press enter (or return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

+ +

To remove a tag, simply click the little "X" icon in the tag.

+ +

Tagging pages that need work

+ +

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

+ +

Tagging obsolete pages

+ +

Use the following tags for pages that are not current:

+ + + +

SEO summary

+ +

The SEO summary is a very short summary of the page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself.

+ +

By default, the first pagragraph of the page is used as the SEO summary. However you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

+ +

Landing pages

+ +

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

+ +
    +
  1. A brief (typically one paragraph) overview of what the technology is and what it's used for. See {{anch("Writing a landing page overview")}} for tips.
    2. +
  2. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
    3. +
  3. An optional "Browser compatibility" section at the bottom of the page.
    4. +
+ +

Creating a page link list

+ +

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

+ +
<div class="row topicpage-table">
+  <div class="section">
+    ... left column contents ...
+  </div>
+  <div class="section">
+    ... right column contents ...
+  </div>
+</div>
+ +

The left column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (for example "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

+ +

The right column should contain one or more of the following sections, in order:

+ +
+
Getting help from the community
+
This should provide information on Matrix chat rooms and mailing lists available about the topic. The heading should use the class "Community".
+
Tools
+
A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".
+
Related topics
+
A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".
+
+ +

<<<finish this once we finalize the landing page standards>>>

+ +

Using, inserting images

+ +

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical. To include an image:

+ +
    +
  1. Attach the desired image file to the article (at the bottom of every article in edit mode)
    2. +
  2. Create an image in the WYSIWYG editor
    3. +
  3. In the WYSIWYG editor in the drop-down list listing attachments, select the newly created attachment which is your image
    4. +
  4. Press OK.
    5. +
+ +

Other References

+ +

Preferred style guides

+ +

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

+ +

Preferred dictionary

+ +

For questions of spelling, please refer to Answers.com. The spell-checker for this site uses American English. Please do not use variant spellings (e.g., use honor rather than honour).

+ +

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

+ +

MDN-specific

+ + + +

Language, grammar, spelling

+ +

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

+ + diff --git a/files/de/mdn/index.html b/files/de/mdn/index.html new file mode 100644 index 0000000000..0c8645cb03 --- /dev/null +++ b/files/de/mdn/index.html @@ -0,0 +1,33 @@ +--- +title: Das MDN Projekt +slug: MDN +tags: + - Landing + - MDN Meta + - 'l10n:priority' +translation_of: MDN +--- +
{{MDNSidebar}}
+ +

Das Mozilla Developer Network (MDN) ist ein Wiki, auf dem wir das Offene Web, Technologien von Mozilla, Firefox OS und andere für Entwickler interessante Themen dokumentieren. WIr freuen uns über jeden, der Inhalte beisteuert oder bearbeitet. Sie müssen kein Programmierer sein oder besonders viel über Technologien wissen; wir haben viele unterschiedliche Aufgaben, vom Einfachen (Korrekturlesen und Beheben von Tippfehlern) bis zum Komplexen (API Dokumentationen schreiben).

+ +
+

Ziel des MDN Projekts ist es, das Offene Web, Mozillas Technologien und Projekte von Mozilla zu dokumentieren. Wir laden Sie ein, dabei zu helfen!

+
+ +

Wir brauchen Ihre Hilfe! Es ist ganz einfach. Machen Sie sich keine Gedanken darüber, um Erlaubnis zu bitten oder Fehler zu machen. Hingegen bitten wir Sie, sich mit der MDN community vertraut zu machen; wir sind da, um Ihnen zu helfen! Die folgende Dokumentation soll Ihnen den Einstieg erleichtern.

+ + + + diff --git a/files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html b/files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html new file mode 100644 index 0000000000..0255388aa1 --- /dev/null +++ b/files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html @@ -0,0 +1,63 @@ +--- +title: Beheben von KumaScript Fehlern +slug: MDN/Kuma/Beheben_von_KumaScript_Fehlern +translation_of: MDN/Tools/KumaScript/Troubleshooting +--- +
{{MDNSidebar}}
+

KumaScript Fehler plaziert in großen roten Kästen wirken auf die Leser abstossend. Zum Glück kann jedoch jeder mit einem MDN Konto solche Fehler beseitigen. Wenn ein Fehler auf einer Seite auftritt, landet die betreffende Seite in der List der Dokumente mit Fehlern.  Seitenauthoren gehen diese Seiten regelmäßig durch um Fehler zu finden und zu beseitigen. Dieser Artikel erläutert vier Typen von KumaScript Fehlern und beschreibt einige Methoden zu ihrer Beseitigung.

+
+ +

DocumentParsingError

+ +

DocumentParsingError tritt auf, wenn KumaScript etwas in dem Dokument nicht versteht. Im allgemeinen handelt es sich um einen Syntaxfehler in einem Makro.

+ +

Beispiele:

+ +
+
Geschweifte Klammern ohne Aufruf eines Makros.
+
Falls \{ in einem Dokument stehen soll ohne ein Makro aufzurufen, kann man einen Schrägstrich \ voranstellen: \\{
+
Sonderzeichen in einem Makro Parameter.
+
Wenn " oder \  innerhalb eines Makro Parameters stehen, kann ein Schrägstrich \ vorangestellt werden: \\ oder \"
+
Fehlende Kommas zwischen den Makro Parametern.
+
Makro Parameters sind mit Kommas (,) zu trennen, jedoch sollte am Ende der Parameterliste kein Komma stehen: z. B. \{\{anch("top", "Back to top")}}.
+
HTML Tags innerhalb eines Makro Aufrufs
+
Makros werden oft durch Textformatiertungen zerstört. So kann z. B. das Tag </code> in den Quellcode des Makros geraten. Die Quellcode Ansicht (source view) zeigt die zu beseitigenden Formatierungselemente.
+
+ + + +

TemplateLoadingError

+ +

TemplateLoadingError Fehler treten auf, wenn KumaScript nicht weiß, welches Makro in die Seite geladen soll.

+ +

Beispiele:

+ +
+
Typos in der Benennung von Makro oder Namensänderungen von Makros.
+
Der Aufruf der Template Seite zeigt die richtigen Namen der Makros. Die URLs für Template Seiten erhält man durch Anheften des Template Namen ans Ende der URL https://developer.mozilla.org/en-US/docs/Template: z.B. ist die Template Seite für \{\{anch("top", "Back to top")}}: https://developer.mozilla.org/en-US/docs/Template:anch.
+
+ Es gibt eine eigene Liste von Makros für MDN, die das gesuchte Makro mit korrekter bzw. neuer Schreibweise enthalten kann.
+
+ +
+

Tipp: Ein gesuchtes Makro ist leicht und schnell durch Hinzufügen eines Suchbegriffs (search keyword) in Firefox zu finden. <<<MEHR DAZU DEMNÄCHST>>

+
+ +

TemplateExecutionError

+ +

TemplateExecutionError Fehler treten auf, wenn KumaScript durch einen Fehler im Makro betroffen wird. Diese Fehler können nur durch Benutzer mit Admin Rechten beseitigt werden, und sollten gemeldet werden (bug report).

+ +

Vor dem Schreiben des Fehlerreports sollte man überprüfen, ob der Fehler nicht bereits beseitigt wurde. Folgendermassen zwingt man KumaScript die Seite neu zu laden:  Shift gedrückt halten und zum Neuladen der Seite drücken: Shift + Ctrl + R unter Windows/Linux, sowie Shift + Cmd + R auf einem Mac.

+ +

Wenn derselbe Fehler wieder auftritt sollte ein Fehlerbericht (bug report) erstellte werden. Dieser Bericht sollte die URL der Seite sowie die Fehlermeldung enthalten.

+ +

Fehler & Unbekannt

+ +

In diese Kategory fallen alle anderen Fehler.

+ +

Diese Fehler sollten auf die selbe Art wie TemplateExecutionError untersucht und beseitigt werden.

+ +

 

+ +

 

diff --git a/files/de/mdn/kuma/index.html b/files/de/mdn/kuma/index.html new file mode 100644 index 0000000000..06e83f21ee --- /dev/null +++ b/files/de/mdn/kuma/index.html @@ -0,0 +1,28 @@ +--- +title: 'Kuma: MDN''s wiki platform' +slug: MDN/Kuma +tags: + - Einstieg bei Mozilla + - Helfen + - Kuma + - MDN Meta + - Mitarbeiten +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/de/docs/MDN")}}
+ +

Kuma ist der Django Code der die MDN Dokumentation unterstützt.

+ +

{{SubpagesWithSummaries}}

+ +

An Kuma mitarbeiten.

+ +

Um an Kuma mit zuarbeiten musst du:

+ + diff --git a/files/de/mdn/nutzer_leitfaden/index.html b/files/de/mdn/nutzer_leitfaden/index.html new file mode 100644 index 0000000000..da9a177a1b --- /dev/null +++ b/files/de/mdn/nutzer_leitfaden/index.html @@ -0,0 +1,8 @@ +--- +title: MDN Benutzerhandbuch +slug: MDN/nutzer_leitfaden +translation_of: MDN/Tools +--- +
{{MDNSidebar}}

Die Mozilla Developer Network-Website ist ein fortschrittliches System zum suchen, lesen und eine beitragene Dokumentions Hilfe für Web-Entwickler (wie auch für Firefox und Firefox OS-Entwickler). Die MDN Mitglieder liefern detailierte Artikel welche zum benutzen des MDN, für Dokumentionen die du brauchst und wenn du möchtest die dir helfen das Material besser und weiter und zu vervollständigen, hilft. 

+ +

{{LandingPageListSubpages}}

diff --git a/files/de/mdn/structures/index.html b/files/de/mdn/structures/index.html new file mode 100644 index 0000000000..f8ea007204 --- /dev/null +++ b/files/de/mdn/structures/index.html @@ -0,0 +1,10 @@ +--- +title: Document structures +slug: MDN/Structures +translation_of: MDN/Structures +--- +
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Throughout MDN, there are various document structures that are used repeatedly, to provide consistent presentation of information in MDN articles. Here are articles describing these structures, so that, as an MDN author, you can recognize, apply, and modify them as appropriate for documents you write, edit, or translate.

+ +

{{LandingPageListSubPages()}}

diff --git a/files/de/mdn/structures/kompatibilitaets_tabellen/index.html b/files/de/mdn/structures/kompatibilitaets_tabellen/index.html new file mode 100644 index 0000000000..758d450e7c --- /dev/null +++ b/files/de/mdn/structures/kompatibilitaets_tabellen/index.html @@ -0,0 +1,500 @@ +--- +title: Kompatibilitäts Tabellen +slug: MDN/Structures/Kompatibilitaets_Tabellen +tags: + - Browser Kompatibilität +translation_of: MDN/Structures/Compatibility_tables +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

MDN hat ein Standard Format für Kompatibilitätstabellen für unsere Offenes Web Dokumentation; Das beeinhaltet die Dokumentation von Technologien, wie zum Beispiel, DOM, HTML, CSS, JavaScript, SVG und viele weitere, welche in jedem Browsern verwendet werden. Dieser Artikel bearbeitet, wie unsere Features verwendet werden sollen um Kompatibilitätsdaten zu den MDN Seiten hinzuzufügen.

+ +
+

Wichtig: Die Art, wie die Daten generiert werden, wurde geändert. Früher wurden unsere Tabellen in die Seite eingefügt und die Daten wurden manuell befüllt. Dies ist Ineffizient, macht die Pflege der Daten schwierig und sorgt für unflexible Daten. Deswegen verschieben wir den Speicher unserer Browserkompatibilitätsdaten in ein Daten Repository (siehe https://github.com/mdn/browser-compat-data) und generieren die Tabellen mit einem Programm.
+
+ In dieser Anleitung dokumentieren wir die neue Art Kompatibilitätsdaten zu MDN hinzuzufügen, aber wir haben die Dokumentation der alten Art immer noch behalten, weil du manuelle Tabellen noch länger auf MDN sehen wirst. Wenn du die alte Dokumentation sehen musst, kannst du unseren Alten Kompatibiltätstabellen Artikel besuchen.

+
+ +
+

Notiz: Wenn du Hilfe zu einem der Schritte dieser Anleitung brauchst, würden wir uns freuen, wenn du uns im MDN Diskussionsforum kontaktierst.

+
+ +

Wie ist das Repository erreichbar?

+ +

Die Daten sind in einem GitHub Repository gespeichert — siehe https://github.com/mdn/browser-compat-data. Um darauf zugreifen zu können, musst du einen GitHub Benutzer erstellen,das browser-compat-data Repository in deinen Account forken, und deinen Fork auf deinen Rechner clonen.

+ +

Wähle ein Feature für das du Daten hinzufügen willst

+ +

Such dir zuerst ein Feature aus, zu dem du Browser-Kompatibilitäts-Daten hinzufügen willst. Das könnte, zum Beispiel ein HTML-Element, eine CSS-Eigenschaft, ein JS-Sprachen-Feature oder ein JS-API-Schnittstelle sein. Wir würden uns wünschen, dass du an API Features arbeitest, da wir bereits Leute haben, die an HTML, JS und CSS arbeiten. Du findest den Status eines Features, für das noch Daten auf das Repository hinzugefügt werden müssen, auf unserer Browser-Kompatibilitäts-Daten Verschiebungstabelle.

+ +

Der Ablauf für das Hinzufügen von Browser-Kompatibilitäts-Daten lautet:

+ +
    +
  1. Öffne die Tabelle und wähle ein Feature an dem nicht schon gearbeitet wird oder bereits übertragen wurde. Schreibe deinen Namen in die "Who" Spalte, wir bevorzugen deinen MDN Nutzernamen, damit wir dich, falls notwendig, über deine E-Mail-Adresse kontaktieren können.
    2. +
  2. Falls das Feature, an dem du Arbeiten willst noch nicht in der Tabelle ist, füge eine Zeile unter Verwendung mit dem gleichen Format und Bennenung ein (z.B. Getrennte Zeilen für unterschiedliche HTML-Elemente, CSS-Eigenschaften, CSS-Selectoren, JS-Objekt und Schnittstellen einer API).
    3. +
  3. Sobald du an einem Feature arbeitest, ändere den Status auf "In progress".
    4. +
  4. Sobald du daten hinzugefügt hast und einen Pull Request zum Main Repo gestellt hast, setze den Status auf "PR done".
    5. +
  5. Wenn deine Daten in das Repo gemerged und zum npm Package hinzugefügt wurden, ändere den Status dementsprechend.
    6. +
  6. Sobald du die Dokumentations-Seite(n) das neue Makro angegeben hast, damit die aktualisierten Tabellen generiert werden, setze den Status auf "Article updated". Damit ist deine Arbeit abgeschlossen.
    7. +
+ +

Preparing to add the data

+ +

Before adding some new data, you should make sure that your fork is up-to-date with the main repo (it contains the same content), create a new branch inside your fork to contain your additions, then pull that branch into your local clone so you can start working inside it:

+ +

Let's look at a simple way to make sure your fork is to-to-date is as follows:

+ +

Adding the main browser-compat-data repo as a remote

+ +

Go to your local clone of your fork in your terminal/command line, and add a remote pointing to the main (upstream) repo like so (you only need to do this once):

+ +
git remote add upstream https://github.com/mdn/browser-compat-data.git
+ +

If you are unsure whether you've done this, you can check what remotes your repo has using

+ +
git remote -v
+ +

Updating your fork with the remote's content

+ +

Now, whenever you want to update your fork, you can do so by:

+ +
    +
  1. +

    Making sure you are in the master branch:

    + + 
    git checkout master
    +
    2. +
  2. +

    fetching the up-to-date repo contents using the following:

    + + 
    git fetch upstream
    +
    3. +
  3. +

    rebasing the contents of your master with the main repo's contents:

    + + 
    git rebase upstream/master
    +
    4. +
  4. +

    pushing these updates back to your remote fork using this:

    + + 
    git push -f
    +
    5. +
+ +

Creating a new branch to do your work in

+ +

Next, go to your remote fork (it will be at https://github.com/your-username/browser-compat-data) and create a new branch to store your changes for this data addition. This can be done by:

+ +
    +
  1. Clicking on the "Branch: Master" button.
    2. +
  2. Entering a new branch name into the "Find or create a branch..." text field.
    3. +
  3. Pressing the resulting "Create branch name-of-branch from Master" button.
    4. +
+ +

For example, if you were wanting to add data for the WebVR API, you'd create a branch called something like "webvr".

+ +

Switching to the new branch

+ +

At this point, go back to your terminal/command line, and update your fork's local clone to include your new branch using the following command:

+ +
git pull
+ +

Now switch to your new branch using this:

+ +
git checkout name-of-branch
+ +

You should now be ready to start adding your data!

+ +

Adding the data

+ +

To add the data, you need to create a new file or files to store your compat data in. The files you need to create differ, depending on what technology you are working on:

+ + + +
+

Note: You'll notice that the repo also contains data for Browser Extensions and HTTP. These data sets are basically finished as they stand, but more features may need to be added in the future.

+
+ +

Each file you create has to follow the pattern defined in the schema contained within our repo; you can see the detailed schema description here.

+ +

Basic compat data structure

+ +

Let's look at an example. CSS property JSON files for example need the following basic structure:

+ +
{
+  "css": {
+    "properties": {
+      "border-width": {
+        "__compat": {
+          ...
+        }
+      }
+    }
+  }
+}
+ +

You have the css object, inside of which is a properties object. Inside the properties object, you need one member for each of the specific features you want to define the compat data for. Each of these members has a __compat member, inside of which the actual data goes.

+ +

The above data is found in the border-width.json file — compare this to the rendered border-width support table on MDN.

+ +

Other types of features work in the same way, but with different object names:

+ + + +
+

In HTML, CSS, and JS pages, you'll normally only need one feature. API interfaces work slightly differently — they always have multiple sub-features (see {{anch("Sub-features")}}, below).

+ +

Basic structure inside a feature

+ +

Inside a feature __compat member, you need to include the following members:

+ + + +

The names of the browser members are defined in the schema (see Browser identifiers). You should use the full list of currently defined identifiers. If you wish to add another browser, talk to us first, as this could have a wide-ranging impact and should not be done without careful thought.

+ +

In a basic browser compat data file, you'll only need to include "version_added" inside the browser identifier members (we'll cover {{anch("Advanced cases")}} later on). The different values you might want to include are as follows:

+ + + +

Inside the status member, you'll include three submembers:

+ + + +

The feature data for border-width (also see border-width.json) is shown below as an example:

+ +
"__compat": {
+  "mdn_url": "https://developer.mozilla.org/docs/Web/CSS/border-width",
+  "support": {
+    "chrome": {
+      "version_added": "1"
+    },
+    "webview_android": {
+      "version_added": "2"
+    },
+    "edge": {
+      "version_added": true
+    },
+    "edge_mobile": {
+      "version_added": true
+    },
+    "firefox": {
+      "version_added": "1"
+    },
+    "firefox_android": {
+      "version_added": "1"
+    },
+    "ie": {
+      "version_added": "4"
+    },
+    "ie_mobile": {
+      "version_added": "6"
+    },
+    "opera": {
+      "version_added": "3.5"
+    },
+    "opera_android": {
+      "version_added": "11"
+    },
+    "safari": {
+      "version_added": "1"
+    },
+    "safari_ios": {
+      "version_added": "3"
+    }
+  },
+  "status": {
+    "experimental": false,
+    "standard_track": true,
+    "deprecated": false
+  }
+}
+ +

Adding a description

+ +

There is a fourth, optional, member that can go inside the __compat member — description. This can be used to include a human-readable description of the feature. You should only include this if it is hard to see what the feature is from glancing at the data. For example, it might not be that obvious what a constructor is from looking at the data structure, so you can include a description like so:

+ +
{
+  "api": {
+    "AbortController": {
+      "__compat": {
+        ...
+      },
+      "AbortController": {
+        "__compat": {
+          "mdn_url": "https://developer.mozilla.org/docs/Web/API/AbortController/AbortController",
+          "description": "<code>AbortController()</code> constructor",
+          "support": {
+            ...
+          }
+        }
+      }
+
+      ... etc.
+    }
+  }
+}
+ +

Sub-features

+ +

In a page where the compat table has more than one row, you'll need multiple subfeatures inside each feature to define the information for each row. This can happen, for example, when you've got the basic support for a feature stored in one row, but then the feature also has a new property or value type that was addded much later in the specification's life and is only supported in a couple of browsers.

+ +

As an example, see the compat data and corresponding MDN page for the background-color property. The basic support exists inside the __compat object as explained above, then you have an additional row for browsers' support for "alpha channel for hex values", which contains its own __compat object.

+ +
{
+  "css": {
+    "properties": {
+      "background-color": {
+        "__compat": {
+          ...
+        },
+        "alpha_ch_for_hex": {
+          "__compat": {
+            ...
+          },
+        }
+      }
+    }
+  }
+}
+ +

For an API, you've got the top two levels defined as api.name-of-the-interface, then a top-level __compat section to define the overall browser compatibility of the interface, then a sub-feature for each of the methods, properties, and constructors contained inside the interface. The basic structure looks like this:

+ +
{
+  "api": {
+    "VRDisplay": {
+      "__compat": {
+        ...
+      },
+      "cancelAnimationFrame": {
+        "__compat": {
+          ...
+        }
+      },
+      "capabilities": {
+        "__compat": {
+          ...
+        }
+      },
+
+      ... etc.
+
+    }
+  }
+}
+ +

See VRDisplay.json for a full example.

+
+ +

Adding data: Advanced cases

+ +

There are some advanced features that you'll want to include in browser compat data. The aim of this section is to list the most common ones, providing an example of each to show how you can implement them in your own compat data.

+ +

Including a footnote

+ +

Often compat tables will include footnotes related to certain entries that explain useful details or strange behavior that developers will find useful. As an example, the Chrome Android entry for {{domxref("VRDisplay.capabilities")}} (see also VRDisplay.json)  (at the time of writing) had a footnote "Currently supported only by Google Daydream." To include this in the capabilities data, we added a "notes" submember inside the relevant "chrome_android" submember; it would look like this:

+ +
"chrome_android": {
+  "version_added": true,
+  "notes": "Currently supported only by Google Daydream."
+}
+ +

Including a vendor prefix

+ +

If a feature is supported behind a vendor prefix in one or more browsers, you'll want to make that clear in the browser compat data. imagine you had a feature that was supported with a -moz- prefix in Firefox. To specify this in the compat data, you'd need to add a "prefix" submember inside the relevant "firefox" submember. It would look something like this:

+ +
"firefox": {
+  "version_added": true,
+  "prefix": "-moz-"
+}
+ +

Including browser preferences or flags

+ +

Some features may be supported in a browser, but they are experimental and turned off by default. If a user wants to play with this feature they need to turn it on using a preference/flag.

+ +

To represent this in the compat data, you need to add the "flags" submember inside the relevant browser identifier submember. The value of "flags" is an array of objects each of which contains of three members:

+ + + +

So to add a preference/flag to the Chrome support for a feature, you'd do something like this:

+ +
"chrome": {
+  "version_added": "50",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "Enable Experimental Web Platform Features",
+      "value_to_set": "true"
+    }
+  ]
+},
+ +

If a feature is behind two or more flags, you can add additional objects to the "flags" array, like in this case, for example:

+ +
"firefox": {
+  "version_added": "57",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "dom.streams.enabled",
+      "value_to_set": "true"
+    },
+    {
+      "type": "preference",
+      "name": "javascript.options.streams",
+      "value_to_set": "true"
+    }
+  ]
+},
+ +

Including a version where support was removed

+ +

Sometimes a feature will be added in a certain browser version, but then removed again as the feature is deprecated. This can be easily represented using the "version_removed" submember, which takes as its value a string representing the version number it was removed on. For example:

+ +
"firefox": {
+  "version_added": "35",
+  "version_removed": "47",
+},
+ +

Including multiple support points for the same browser entry

+ +

Sometimes you'll want to add multiple support data points for the same browser inside the same feature.

+ +

As an example, the {{cssxref("text-align-last")}} property (see also text-align-last.json) was added to Chrome in version 35, supported behind a pref.

+ +

The support mentioned above was then removed in version 47; also in version 47, support was added for text-align-last enabled by default.

+ +

To include both of these data points, you can make the value of the "chrome" submember an array containing two support information objects, rather than just a single support information object:

+ +
"chrome": [
+  {
+    "version_added": "47"
+  },
+  {
+    "version_added": "35",
+    "version_removed": "47",
+    "flags": [
+      {
+        "type": "preference",
+        "name": "Enable Experimental Web Platform Features",
+        "value_to_set": "true"
+      }
+    ]
+  }
+],
+ +
+

Note: You should put the most current or important support point first in the array — this makes the data easier to read for people who just want to scan it for the latest info.

+
+ +

Including an alternative name

+ +

Occasionally browsers will support a feature under a different name to the name defined in its specification. This might be for example because a browser added experimental support for a feature early, and then the name changed before the spec stabilized.

+ +

To include such a case in the browser compat data, you can include a support information point that specifies the alternative name inside an "alternative_name" member.

+ +
+

Note: The alternative name might not be an exact alias — it might have differing behaviour to the standard version.

+
+ +

Let's look at an example. The {{cssxref("border-top-right-radius")}} property (see also border-top-right-radius.json) was supported in Firefox:

+ + + +

To represent this in the data, we used the following JSON:

+ +
"firefox": [
+  {
+    "version_added": "4",
+    "notes": "Prior to Firefox 50.0, border styles of rounded corners were always rendered as if <code>border-style</code> was solid. This has been fixed in Firefox 50.0."
+  },
+  {
+    "prefix": "-webkit-",
+    "version_added": "49",
+    "notes": "From Firefox 44 to 48, the <code>-webkit-</code> prefix was available with the <code>layout.css.prefixes.webkit</code> preference. Starting with Firefox 49, the preference defaults to <code>true</code>."
+  },
+  {
+    "alternative_name": "-moz-border-radius-topright",
+    "version_added": "1",
+    "version_removed": "12"
+  }
+],
+ +

Pushing a change back to the main repo

+ +

Once you are finished with adding your compat data, you should first test it using the following commands:

+ + + +

If it is looking OK, you then need to commit it and push it back up to your remote fork on GitHub. You can do this easily with terminal commands like this:

+ +
git add .
+git commit -m 'adding compat data for name-of-feature'
+git push
+ +

Now go to your remote fork (i.e. https://github.com/your-username/browser-compat-data) and you should see information about your push at the top of the files list (under "Your recently pushed branches"). You can create a pull request (starting the process of pushing this to the main repo) by pressing the "Compare & pull request" button, then following the simple prompts on the subsequent screen.

+ +

At this point, you just need to wait. A reviewer will review your pull request, and merge it with the main repo, OR request that you make changes. If changes are needed, make the changes and submit again until the PR is accepted.

+ +

Inserting the data into MDN pages

+ +

Once your new data has been included in the main repo, you can start dynamically generating browser compat tables based on that data on MDN pages using the \{{Compat}} macro. This takes a single parameter, the dot notation required to walk down the JSON data and find the object representing the feature you want to generate the compat table for.

+ +

Above the macro call, to help other contributors finding their way, you should add a hidden text that is only visible in MDN contributors in edit mode:

+ +
<div class="hidden">
+<p>The compatibility table on this page is generated from structured data.
+If you'd like to contribute to the data, please check out
+<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>
+and send us a pull request.</p>
+</div>
+ +

As an example, on the {{httpheader("Accept-Charset")}} HTTP header page, the macro call looks like this: \{{Compat("http.headers.Accept-Charset")}}. If you look at the accept-charset.json file in the repo, you'll see how this is reflected in the JSON data.

+ +

As another example, The compat table for the {{domxref("VRDisplay.capabilities")}} property is generated using \{{Compat("api.VRDisplay.capabilities")}}. The macro call generates the following table (and corresponding set of notes):

+ +
+ + +

{{Compat("api.VRDisplay.capabilities")}}

+ +
+

Note: The filenames often match the labels given to the interfaces inside the JSON structures, but it is not always the case. When the macro calls generate the tables, they walk through all the files until they find the relevant JSON to use, so the filenames are not critical. Saying that, you should always name them as intuitively as possible.

+
diff --git "a/files/de/mdn/\303\274ber/index.html" "b/files/de/mdn/\303\274ber/index.html" new file mode 100644 index 0000000000..745152be79 --- /dev/null +++ "b/files/de/mdn/\303\274ber/index.html" @@ -0,0 +1,99 @@ +--- +title: Über MDN +slug: MDN/Über +translation_of: MDN/About +--- +
{{MDNSidebar}}
+ +
{{IncludeSubNav("/en-US/docs/MDN")}}
+ +

MDN Web Docs ist eine sich entwickelnde Lernplattform für Web-Techniken und Software, die das Web antreibt, einschließlich:

+ + + +

Unsere Mission

+ +

MDNs Mission ist einfach: Entwickler mit den Informationen versorgen, die sie benötigen, um Projekte für ein offenes Web einfach umzusetzen. Wenn es sich um eine offene Technik für das Web handelt, möchten wir sie dokumentieren.

+ +

Darüber hinaus stellen wir die Dokumentation zu Mozilla-Produkten zur Verfügung und wie man Mozilla-Projekte erstellt und zu ihnen beiträgt.

+ +

Wenn du dir nicht sicher bist, ob ein bestimmtes Thema für MDN geeignet ist, lies: Gehört das zu MDN?

+ +

Wie du helfen kannst

+ +

Du musst nicht programmieren — oder gut schreiben können — um bei MDN beitragen zu können! Es gibt viele Möglichkeiten zu unterstützen. Vom Korrekturlesen von Artikeln, um sicherzustellen, dass sie verständlich sind, über das Beitragen von Texten, bis zum Hinzufügen von Beispiel-Quelltexten. Tatsächlich gibt es so viele Arten zu helfen, dass wir eine Erste Schritte-Seite erstellt haben, die dir dabei helfen soll, zu erledigende Aufgaben nach deinen Interessen und der zur Verfügung stehenden Zeit auszuwählen!

+ +

Du kannst uns auch helfen MDN bekannter zu machen, in dem du es auf deinem Blog oder deiner Website erwähnst.

+ +

Die MDN-Gemeinschaft

+ +

Unsere Gemeinschaft ist global! Wir haben Mitwirkende aus der ganzen Welt, in einer Vielzahl an Sprachen. Wenn du mehr über uns erfahren möchtest, oder auf irgendeine Art Hilfe bei MDN benötigst, zögere nicht unser Diskussionsforum oder unseren IRC-Kanal zu besuchen! Du kannst auch auf dem Laufenden bleiben in dem du unserem Twitter-Konto unter @MozDevNet folgst. Auf diese Art kannst du auch Tweets an uns senden, falls dir Unstimmigkeiten auffallen, du uns deine Meinung sagen oder ein großes Dankeschön an unsere Autoren und Mitwirkenden senden möchtest!

+ +

Verwendung der MDN Web Docs-Inhalte

+ +

Urheberrecht und Lizenzen

+ +

MDN wiki documents have been prepared with the contributions of many authors, both within and outside the Mozilla Foundation. Unless otherwise indicated, the content is available under the terms of the Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 or any later version. Please attribute "Mozilla Contributors" and include a hyperlink (online) or URL (in print) to the specific wiki page for the content being sourced. For example, to provide attribution for this article, you can write:

+ +
About MDN by Mozilla Contributors is licensed under CC-BY-SA 2.5.
+ +

Note that in the example, "Mozilla Contributors" links to the history of the cited page. See Best practices for attribution for further explanation.

+ +
+

See MDN content on WebPlatform.org for information about how to reuse and attribute MDN content on that site.

+
+ +

Code samples added to this wiki before August 20, 2010 are available under the MIT license; you should insert the following attribution information into the MIT template: "© <date of last wiki page revision> <name of person who put it in the wiki>".

+ +

Code samples added on or after August 20, 2010 are in the public domain. No licensing notice is necessary, but if you need one, you can use: "Any copyright is dedicated to the Public Domain. http://creativecommons.org/publicdomain/zero/1.0/".

+ +

If you wish to contribute to this wiki, you must make your documentation available under the Attribution-ShareAlike license (or occasionally an alternative license already specified by the page you are editing), and your code samples available under Creative Commons CC-0 (a Public Domain dedication). Adding to this wiki means you agree that your contributions will be made available under those licenses.

+ +

Some older content was made available under a license other than the licenses noted above; these are indicated at the bottom of each page by way of an Alternate License Block.

+ +
+

Es dürfen keine neuen Seiten unter Verwendung anderer Lizenzen erstellt werden.

+
+ +

Das Urheberrecht für beigetragenes Material verbleibt beim Autor, bis der Autor es auf jemand anderen überträgt.

+ +

Wenn du Fragen oder Bedenken betreffs der hier diskutierten Belange hast, kontaktiere bitte Eric Shepherd.

+ +
+

Die Rechte an den Markenzeichen, Logos und Dienstleistungsmarken der Mozilla Foundation, sowie die Gestaltung dieser Website, stehen nicht unter der Creative Commons-Lizenz, and to the extent they are works of authorship (wie Logos und grafische Entwürfe), sie sind nicht Bestandteil der Werke die unter diesen Bedingungen lizenziert sind. If you use the text of documents, and wish to also use any of these rights, or if you have any other questions about complying with our licensing terms for this collection, you should contact the Mozilla Foundation here: licensing@mozilla.org.

+ +

Inhalte herunterladen

+ +

Du kannst ein vollständiges, gespiegeltes Archiv von MDN (2.5 GB, Stand: 2016-11-30) herunterladen.

+ +

Einzelne Seiten

+ +

Du kannst den Inhalt einer einzelnen Seite von MDN abfragen, in dem du den Dokumentparameter, mit dem du auch gleich das Dateiformat festlegst, zur URL hinzufügst.

+ +

Werkzeuge von Dritten

+ +

Du kannst dir MDN-Inhalte durch Werkzeuge, die von Dritten erstellt wurden, ansehen, wie zum Beispiel Dash (für Mac OS) und Zeal (für Linux und Windows).

+ +

Kapeli veröffentlich auch offline MDN docs, die die Bereiche HTML, CSS, JavaScript, SVG und XSLT abdecken.

+ +

Verlinken auf MDN

+ +

Lies diesen Artikel für eine Anleitung und die beste Vorgehensweise beim Verlinken auf MDN.

+ +

Probleme mit MDN Web Docs melden

+ +

Siehe Wie kann man auf MDN ein Problem melden.

+ +

Geschichte der MDN Web Docs

+ +

Das Projekt MDN Web Docs (zuvor Mozilla Developer Network (MDN), zuvor Mozilla Developer Center (MDC), a.k.a. Devmo) startete im Jahr 2005 als die Mozilla Foundation eine Lizenz von AOL erhielt um die originalen Netscape DevEdge-Inhalte nutzen zu dürfen. Die DevEdge-Inhalte wurden dann nach noch brauchbarem Material durchsucht, welches dann von Freiwilligen in dieses Wiki übertragen wurde, so dass es leichter aktuell zu halten und zu warten wäre.

+ +

Du kannst mehr über die Geschichte von MDN auf unserer Seite über die Feier zum 10. Jubiläum erfahren, einschließlich mündlicher Berichte von einigen der daran Beteiligten.

+ +

Über Mozilla

+ +

Whether you want to learn more about who we are, how to be a part of Mozilla or just where to find us, you've come to the right place. To find out what drives us and makes us different, please visit our mission page.

diff --git "a/files/de/mdn/\303\274ber/link_zu_mdn/index.html" "b/files/de/mdn/\303\274ber/link_zu_mdn/index.html" new file mode 100644 index 0000000000..47411ecf30 --- /dev/null +++ "b/files/de/mdn/\303\274ber/link_zu_mdn/index.html" @@ -0,0 +1,82 @@ +--- +title: Verknüpfung zu MDN +slug: MDN/Über/Link_zu_MDN +tags: + - Anleitung + - MDN Meta + - Richtlinien +translation_of: MDN/About/Linking_to_MDN +--- +
{{MDNSidebar}}

Wir bekommen regelmässige Anfragen von Benutzern, wie Verknüpfungen (Link) zu MDN erstellt werden können, und ob dies überhaupt erlaubt ist. Die kurze Antwort ist: Ja! Wie das am besten zu bewerkstelligen ist, wird im folgenden Abschnitt erklärt, bitte weiterlesen!

+ +

Darf ich zu MDN verknüpfen?

+ +

Ja! Absolut! Nicht nur ist der Link die Essenz des Webs, es ist gleichzeitig ein Weg den Benutzer auf glaubwürdige Quellen zu verweisen, sondern auch um die Arbeit zu zeigen, die die Community macht.

+ +

Also, ja, wir bitten dich definitiv auf den Inhalt von MDN zu verknüpfen. Bitte nicht zögern: verknüpfe zur MDN Hauptseite, oder, besser, verknüpfe tiefer zu einer spezifischen Seite in MDN, so wie angebracht. Für eine genaue Beschreibung zu welchen Seiten verknüpft werden kann, ist weiter unten nachzulesen.

+ +

Zu welcher Seite sollte ich verknüpfen?

+ +

Es gibt keine spezifische Seite zu der man sich verknüpfen kann. Was wichtig ist, ist wie relevant die Seite für eure Leser ist.

+ + + +

Aber, wirklich, es sollte zur am besten passenden Seite für die Benutzer verknüpft werden. Bitte nicht vergessen, das wichtigste ist der Leser, nicht die Verknüpfung oder wir.

+ +

Wie wird eine gute Verknüpfung erstellt?

+ +

Eine Verknüpfung zu erstellen ist einfach, aber eine gute Verknüpfung zu erstellen ist umso schwieriger. Es gibt verschiedene Möglichkeiten:

+ +

Verknüpfen im Text

+ +

Dies ist wohl die hilfreichste Art der Verknüpfung: der Sinn besteht darin, den Benutzer zu weiteren Informationen zu einem bestimmten Konzept zu leiten. Die meiste Zeit, führen diese Verknüpfungen zu Seiten, die bestimmte Informationen zu einem Thema enthalten und nicht zu einer generellen Heimseite eines Webauftritts (es gibt bestimmt auch Ausnahmen).

+ +
+

… durch die Benutzung der IndexedDB-API, können Informationen in einer lokalen Datenbank gespeichert werden…

+
+ +

Solche Verknüpfungen sind nicht nur für den Benutzer wertvoll, welcher alle relevanten Informationen mit einem Klick finden kann, sondern auch für MDN, weil dieser präzise Kontext womöglich Leser dazu bringt, den Inhalt von MDN zu mögen. Unsere Mission besteht darin, dem Leser zu helfen, alle wichtigen Informationen zu einem Thema schnellstmöglich zu finden.

+ +

Was zu vermeiden ist, wenn Verknüpfungen im Text erstellt werden

+ +

Verknüpfungen im Text sind gut und hilfreich, aber es sollten einige Dinge beachtet werden:

+ + + +

Ein Banner oder ein Bild zur Site hinzufügen

+ +

Ein anderer Weg um zu MDN zu verknüpfen ist das Hinzufügen einer Bildverknüpfung ausserhalb des Textes, zum Beispiel in der Seitenleiste. Dies hat eine andere Bedeutung: so wie die Verknüpfung innerhalb des Textes zusätzliche Informationen für den Benutzer zugängig macht, ist das Hinzufügen von Bildverknüpfungen in der Seitenleiste mehr ein Weg um die Unterstützung vom MDN-Projekt hervorzuheben, oder ein Weg um MDN bekannter zu machen. Es ist ein Weg um MDN als globale Quelle von Informationen anzubieten.

+ +

Bitte nicht zögern um uns ihre Unterstützung zu zeigen: besuchen Sie Promote MDN und bauen Sie eine Schaltfläche (Button), welche auf Ihre Webseite zugeschnitten ist. Sie sind selbstverständlich frei zu anderen Seiten zu verknüpfen, wie zum Beispiel zu einer der Landungsseiten.

+ +

Automatische Verknüpfung zu MDN aus WordPress

+ +

Wir haben ein WordPress plugin erstellt, welches automatisch aus den Blogs heraus, Verknüpfungen zu den entsprechenden MDN-Seiten erstellt. Es verfolgt die oben gezeigten Richtlinien, und bildet so eine grosse Hilfe für Blogger, die über Webinhalte schreiben. Geben Sie ein schönes Aussehen und installieren Sie es wo es hilfreich sein kann.

+ +

Vielen Dank für die Unterstützung!

+ +

Cross-Origin Ressourcenfreigabe

+ +

Unsere Absicht ist CORS auf allen frei zugänglichen Informationen auf MDN anzubieten, wo es ungefährlich ist. Sollten Sie etwas finden was nicht erreicht werden kann mit cross-origin Anfragen, ist dies ein Fehler der behoben werden sollte!

-- cgit v1.2.3-54-g00ecf