From 4ab365b110f2f1f2b736326b7059244a32115089 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:45:38 +0100 Subject: unslug de: move --- files/de/mdn/about/index.html | 99 ++++ files/de/mdn/at_ten/history_of_mdn/index.html | 228 +++++++++ files/de/mdn/at_ten/index.html | 40 ++ .../community/bleibe_auf_dem_laufenden/index.html | 42 -- files/de/mdn/community/index.html | 80 --- .../howto/do_a_technical_review/index.html | 54 -- .../howto/do_an_editorial_review/index.html | 49 -- .../howto/erstellung_eines_mdn_profils/index.html | 50 -- .../index.html" | 81 --- .../howto/set_the_summary_for_a_page/index.html | 54 -- files/de/mdn/contribute/zu_tun_im_mdn/index.html | 28 -- files/de/mdn/guidelines/style_guide/index.html | 560 --------------------- .../mdn/guidelines/writing_style_guide/index.html | 560 +++++++++++++++++++++ .../kuma/beheben_von_kumascript_fehlern/index.html | 63 --- files/de/mdn/kuma/index.html | 28 -- files/de/mdn/nutzer_leitfaden/index.html | 9 - .../mdn/structures/compatibility_tables/index.html | 500 ++++++++++++++++++ .../kompatibilitaets_tabellen/index.html | 500 ------------------ files/de/mdn/tools/index.html | 9 + .../tools/kumascript/troubleshooting/index.html | 63 +++ files/de/mdn/yari/index.html | 28 ++ "files/de/mdn/\303\274ber/index.html" | 99 ---- "files/de/mdn/\303\274ber/link_zu_mdn/index.html" | 82 --- 23 files changed, 1527 insertions(+), 1779 deletions(-) create mode 100644 files/de/mdn/about/index.html create mode 100644 files/de/mdn/at_ten/history_of_mdn/index.html create mode 100644 files/de/mdn/at_ten/index.html delete mode 100644 files/de/mdn/community/bleibe_auf_dem_laufenden/index.html delete mode 100644 files/de/mdn/community/index.html delete mode 100644 files/de/mdn/contribute/howto/do_a_technical_review/index.html delete mode 100644 files/de/mdn/contribute/howto/do_an_editorial_review/index.html delete mode 100644 files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html delete mode 100644 "files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" delete mode 100644 files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html delete mode 100644 files/de/mdn/contribute/zu_tun_im_mdn/index.html delete mode 100644 files/de/mdn/guidelines/style_guide/index.html create mode 100644 files/de/mdn/guidelines/writing_style_guide/index.html delete mode 100644 files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html delete mode 100644 files/de/mdn/kuma/index.html delete mode 100644 files/de/mdn/nutzer_leitfaden/index.html create mode 100644 files/de/mdn/structures/compatibility_tables/index.html delete mode 100644 files/de/mdn/structures/kompatibilitaets_tabellen/index.html create mode 100644 files/de/mdn/tools/index.html create mode 100644 files/de/mdn/tools/kumascript/troubleshooting/index.html create mode 100644 files/de/mdn/yari/index.html delete mode 100644 "files/de/mdn/\303\274ber/index.html" delete mode 100644 "files/de/mdn/\303\274ber/link_zu_mdn/index.html" (limited to 'files/de/mdn') diff --git a/files/de/mdn/about/index.html b/files/de/mdn/about/index.html new file mode 100644 index 0000000000..745152be79 --- /dev/null +++ b/files/de/mdn/about/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/at_ten/history_of_mdn/index.html b/files/de/mdn/at_ten/history_of_mdn/index.html new file mode 100644 index 0000000000..3e33c984f3 --- /dev/null +++ b/files/de/mdn/at_ten/history_of_mdn/index.html @@ -0,0 +1,228 @@ +--- +title: MDNs Geschichte +slug: MDN_at_ten/History_of_MDN +tags: + - MDN +translation_of: MDN_at_ten/History_of_MDN +--- +
+

In diesem Gespräch schauen mehrere Mitwirkende von MDN auf die vergangenen zehn Jahre von developer.mozilla.org zurück und auf das kommende Jahrzehnt. Du wirst die Geschichte verschiedener Wiki-Software-Migrationen hören, wie eine Gemeinschaft rund ums Dokumentieren entstanden ist und viele weitere Highlights der Geschichte dieser Seite. Anschließend spricht die Gruppe auch über aktuelle Herausforderungen und Projekte, an denen die MDN Gemeinschaft dieses Jahr arbeitet.

+ +
+ +
+ +
+
Justin Crawford + +

Justin Crawford Produktmanager, MDN

+ +

Justin moderiert dieses Gespräch und macht Dinge mit Code, Wörtern, Fahrradteilen und moderates this talk and makes things with code, words, bike parts, and Trödelkram. Er ist @hoosteeno auf Twitter.

+
+ +
+

Was ist MDN und für wen ist es? Ein Platz für die Gemeinschaft des Open Web

+ +

MDN bietet nützliche Informationen rund um Web Technologien und fördert das Lernen, Teilen und Schulen innerhalb der Open Web Gemeinschaft. Auf MDN kommen die Leute zusammen und erstellen Dinge für dich und für andere.

+Ein Platz für Mozilla Entwickler + +

MDN ist auch ein Platz für Mozilla Entwickler, wie Gecko oder Firefox Programmierer, Add-on Entwickler und Firefox OS Mitwirkende.

+
+ +
Eric Shepherd + +

Eric "Sheppy" Shepherd Technischer Autor, MDN

+ +

Sheppy ist hier und dokumentiert für Mozilla seit 2006 und hat eine lange Geschichte (und verrückte Ideen) im Zusammenhang mit MDC und MDN. Er ist @sheppy auf Twitter.

+
+ +
+

Die Geschichte von MDN Ära vor Wiki – Netscape DevEdge

+ +

In den frühen Jahren gab es DevEdge, die Entwicklerdokumentation von Netscape, welche die Basis für einen Teil der Dokumentation auf MDN bildet. Schau dir die Vergangenheit auf archive.org an:

+ +

Netscape DevEdge

+ +

Am 12. Oktober 2004 wurde diese beliebte Entwicklerwebseite von AOL, Netscapes Mutterkonzern, abgeschaltet. Nur ein paar Monate später, im Februar 2015 konnte Mitchell Baker DevEdge retten und eine Vereinbarung mit AOL aushandeln, die es Mozilla erlaubte, basierend auf den früheren Netscape DevEdge Materialien neue Dokumente zu posten, zu verändern und zu erstellen. Mit anderen Worten, was 1998 mit dem Mozilla Quellcode geschehen ist, passierte schließlich auch mit Netscapes Entwicklerdokumentation: Sie wurde quelloffen.

+ +

Deb Richardson ist der Mozilla Foundation als technische Autorin beigetreten und leitete das neue DevMo Projekt für die von der Gemeinschaft geleitete Dokumentation.

+
+ +
+

MediaWiki Die erste Wiki-Engine

+ +

Mit MediaWiki als neuer darunterliegender Projektplatform wurde die Mozilla Entwicklerdokumentation im Juli 2005 für jedermann bearbeitbar gemacht. Es wurde ein neues kollaboratives Element in Mozilla eingeführt und seit diesem Augenblick ist jeder willkommen, um es zu verbessern und sein Wissen zu teilen. Eine neue internationale Gemeinschaft begann zu wachsen und Entwicklerinhalte in andere Sprachen zu übersetzen.

+ +

MDC MediaWiki

+
+ +
Florian Scholz + +

Florian Scholz Technischer Autor, MDN

+ +

Florian ist ein technischer Autor bei Mozilla, der sich auf Technologien des Open Web fokussiert. Er ist ein Wikizwerg, der die Dokumentation pflanzt als wäre sie Blumen, und er mag es, gemeinsam mit der Gemeinschaft an dem Ziel zu arbeiten, das Web zu dokumentieren und es für jeden zugänglich zu machen. Florian ist passioniert gegenüber Open Source. Er wohnt in Bremen, Deutschland, und tweetet als @floscholz auf Twitter.

+
+ +
+

DekiWiki Die zweite Wiki-Engine

+ +

Im August 2008 wechselte das Mozilla Developer Center zu MindTouch DekiWiki, einem leistungsstarken und neuen Content Management System und Wiki System für technische Dokumentation. Dieser Plattformwechsel wurde in der Gemeinschaft kontrovers aufgenommen, die MediaWiki seit 2005 gewohnt war und Werkzeuge dafür entwickelt hatte.

+ +

MDC DekiWiki

+
+ +
Ali Spivak + +

Ali Spivak Hirtin der fantastischen MDN-Katzen

+ +

Ali Spivak managt Inhalt und Gemeinschaft im Mozilla Developer Network und verbringt ihre Zeit damit, sich Wege auszudenken, die helfen, das Web noch toller zu geschalten. Sie kümmert sich darum, dass das Web offen und frei bleibt und, nachdem sie durch ihren Beitritt zu Mozilla 2012 mit Open Source in Berührung gekommen ist, konzentriert sie sich darauf, die Entwicklercommunities bei Mozilla zu stärken und daran teilzunehmen. Sie ist @alispivak auf Twitter.

+
+ +
+

Kuma Die dritte und aktuelle Wiki-Engine

+ +

Kuma, das sich Anfang 2011 von Kitsune abgezweigt hat und am 3. August 2012 veröffentlicht wurde, ist eine von Mozilla entwickelte Wikiplattform basierend auf Django, mit seinem eigenen KumaScript Makrosystem, welches Node.js verwendet.

+ +

Dadurch, dass der Code auf GitHub lebt, fing die Gemeinschaft an, ebenfalls an MDNs CMS mitzuwirken. Seit diesem Zeitpunkt beinhaltet Programmieren auf MDN beides, die Dokumentation zu schreiben und Kuma zu entwickeln.

+ +

MDN KUMA

+
+ +
David Walsh + +

David Walsh Webentwickler, MDN

+ +

Mozilla Senior Webentwickler, Front-End Engineer, MooTools Hauptentwickler, JavaScript Fanatiker, CSS Tüftler, PHP Hacker, Web und Open Source Liebhaber. David ist @davidwalshblog auf Twitter.

+
+ +
+

Neugestaltung von MDN Kuma mit erneuertem Design

+ +

Das Redesign von MDN war ein Großprojekt. Sean Martell entwarf MDNs neues Erscheinungsbild. Zu der Zeit war es ein iterativer Prozess mit einer Beta-Benutzergruppe von 3000 MDN-Leuten, der mehrere Monate in Anspruch genommen hat. Das neue Aussehen war hinter einem "Waffle Flag" (MDNs Featureflag System). Großer Dank auch an David Walsh, der das gesamte Redesign meisterte und MDN das Frontend gab, das es verdient.

+Waffle flag
+ +
Janet Swisher + +

Janet Swisher Community Managerin, MDN

+ +

Janet ist eine Mozilla Community Managerin für das Mozilla Developer Network. She trat Mozilla 2010 bei und hat seit 2004 mit Open Source Software zu tun und mit technischer Kommunikation seit dem 20. Jahrhundert. Sie lebt in Austin, Texas, mit ihrem Ehemann und einem Pudel. Sie ist @jmswisher auf Twitter.

+
+ +
+

Gemeinschaft rund um Open Web Dokumentation Von der Gemeinschaft geleitete, browserunabhängige Open Web Dokumentation

+ +

Irgendwann 2010, insbesondere als sich Mitglieder der Gemeinschaft und technische Autoren in Paris trafen, wurde deutlich, dass sich MDNs Fokus weg von "Lass uns alles rund um Firefox dokumentieren!" hin zu "Lass uns das Web dokumentieren!" bewegt. Die Dokumentation wurde über die letzten Jahre bereinigt und umstrukturiert, sodass MDNs Open Web Dokumentation browserunabhängig ist. Dieses Material, das für alle nützlich ist, die für das Web entwickeln, ist der beliebteste und am häufigsten benutzte Inhalt.

+ +

Verschiedene Browserhersteller haben von Zeit zu Zeit dazu beigetragen, diesen Teil von MDN mitzugestalten. Diese browserübergreifende Zusammenarbeit war sehr erfolgreisch und wurde von den MDN Lesern sehr geschätzt.

+
+ +
Luke Crouch + +

Luke Crouch Webentwickler, MDN

+ +

Luke Crouch ist ein Hobbybrauer, Fußballfan und Webentwickler für Mozilla. Er arbeitet am Web seit 1996 und benutzt Firefox seit 2004, schreibt Open Source Software seit 2006 und trat 2010 Mozilla als erster angestellter MDN-Webentwickler bei. Luke ist @groovecoder auf Twitter.

+
+ +
+

Übersetzungscommunities MDN dient einem globalen Publikum in vielen Sprachen

+ +

Übersetzung ist ein großer Teil der Mozilla Gemeinschaft; sie ist eine Komponente fast jedes Projekts und Produkts. Durch Kuma ist MDN ebenfalls sehr leicht übersetzbar und angepasst an unsere Übersetzercommunity. Die W3C-Spezifikationen und andere Ressourcen, die die Funktionalität des Webs beschreiben, haben keine genauen Ziele und haben Communities, die Spezifikationen in mehreren Sprachen erstellen. Besonders für Einsteiger ist MDN der erste Schritt zur Erkundung der Webtechnologien, daher ist es unser Ziel, für jeden da zu sein. MDN hat ein breites Publikum und will nicht nur englische Muttersprachler einbinden. Es wird in aller Welt geschätzt.

+
+ +
Julien + +

Julien (a.k.a. Sphinx) Französische Übersetzung, MDN

+ +

Julien verbringt viele Nächte und Wochenenden damit, JavaScript-Artikel in französisch zu übersetzen. Er ist kein Programmierer, aber hat einen IT-Hintergrund und will mehr über neue Technologien lernen. Er arbeitet lieber an MDN mit anstatt fernzusehen.

+
+ +
an-Yves Perrier + +

Jean-Yves Perrier Technischer Autor, MDN

+ +

Jean-Yves ist seit 2010 technischer Autor für MDN und trat Mozilla 2011 als Vollzeitmitarbeiter bei. Er liebt das Open Web mit 15 Jahren Erfahrung C++. Er ist Schweizer, aber lebt in London, England. Seine Erdős-Zahl ist 5 und er ist @Teoli2003 auf Twitter.

+
+ +
+

Lernbereich

+ +

Die Learning Area ist ein neues Bestreben, grundlegende Webfähigkeiten zu vermitteln. Über die letzten 10 Jahre hat MDN viel fortgeschrittenes Material hinzugefügt, das Experten wertvolle Informationen bietet. Dieses Projekt liefert Materialien für Anfänger und versucht, viele Wissenslücken zu schließen.

+
+ +
Jérémie Patonnier + +

Jérémie Patonnier Technischer Autor, MDN

+ +

Jérémie ist langjähriger Mitwirkender am Mozilla Developer Network und ein professioneller Webentwickler seit 2000. Er verfechtet Webstandards und schreibt Dokumentation über Webtechnologien mit dem Ziel, sie für jeden zugänglich zu machen. Er ist @JeremiePat auf Twitter.

+
+ +
+

MDNs Zukunft Was wird anders sein, wenn wir 20 Jahre MDN feiern?

+ +

Jeder, der an MDN arbeitet, engagiert sich dafür, dass das Web offen und zugänglich ist, und das ist der Grund warum wir die Übersetzerteams und all die mitwirkenden Leute haben. MDN hofft, weiterhin eine Schlüsselrolle darin zu spielen, das Web so zu bewahren, wie wir finden, dass es sein sollte.

+ +

Ein großer Teil dieser Zukunft werden Lernmaterialien sein. Es wird die nächsten zehn Jahre wesentlich mehr Webentwickler geben.

+ +

Ein weiterer großer Teil unserer Arbeit besteht darin, die bereits bestehenden Informationen zu pflegen und zu aktualisieren, sodass wir Webentwicklern immer relevanten Inhalt bieten.

+ +

Was sich ändert und in Zukunft wahrscheinlich noch mehr, ist, wie Informationen konsumiert werden. Heute suchen Leute nach Information und schauen in der Dokumentation nach. In Zukunft könnte MDN Dokumentation in Codeeditoren, den Firefox Entwicklertools und vielen anderen Entwicklertools und Services zur Verfügung stehen.

+
+ +
+

Erwähnenswerte Mitwirkende Viele weitere Leute leisten fantastische Arbeit auf MDN

+ +
+
    +
  • Les Orchard
    • +
  • John Karahalis
    • +
  • David Walsh
    • +
  • Jannis Leidel
    • +
  • Stephanie Hobson
    • +
  • James Bennett
    • +
  • Isac Lagerblad
    • +
  • Piotrek Koszuliński
    • +
  • Craig Cook
    • +
  • Rob Hudson
    • +
  • John Whitlock
    • +
  • ...
    + Und viele weitere Kuma Mitwirkende.
    • +
+ + +
    +
  • Chris Mills
    • +
  • Will Bamberg
    • +
  • David Bruant
    • +
  • Thierry Régagnon
    • +
  • etherthank
    • +
  • Saurabh Nair
    • +
  • Deb Richardson
    • +
  • Sebastian Zartner
    • +
  • Tooru Fujisawa
    • +
  • Karen Scarfone
    • +
  • Niklas Barning
    • +
  • ...
    + Und hunderte weiterer Wiki-Mitarbeiter.
    • +
+
+The Berlin Office
+ +
 
+
+
diff --git a/files/de/mdn/at_ten/index.html b/files/de/mdn/at_ten/index.html new file mode 100644 index 0000000000..91495de944 --- /dev/null +++ b/files/de/mdn/at_ten/index.html @@ -0,0 +1,40 @@ +--- +title: 10 Jahre MDN +slug: MDN_at_ten +tags: + - MDN + - TopicStub +translation_of: MDN_at_ten +--- + + +
+
+

Die Geschichte des MDN

+ +

Anfang 2005 machte es sich ein kleines Team von Idealisten zum Ziel eine neue, freie und von einer Gemeinschaft geförderte Online-Resource für alle Webentwickler zu schaffen. Ihre brillante, wenn auch ungewöhnliche Idee entwickelte sich zum heutigen Mozilla Developer Network — die wichtigste Informationsquelle für alle offenen Webtechnologien. Zehn Jahre später ist unsere globale Gemeinschaft grösser als je zuvor und gemeinsam erstellen wir noch immer Dokumentationen, Beispielcode und Lernmaterialien für alle offenen Webtechnologien, darunter CSS, HTML, JavaScript und alles andere, was das Web so mächtig macht wie wir es kennen.

+ +

Mehr erfahren about the history

+ + +

Zum MDN beitragen

+ +

Seit zehn Jahren dokumentiert die MDN Gemeinschaft bereits das offene Web. Von der Korrektur kleiner Tippfehler bis zum Schreiben verschiedener Folgen über brandneue APIs: Jede und jeder kann etwas beitragen und kein Beitrag ist zu gross oder zu klein. Wir verfügen über 90.000 Seiten an Inhalt, welche von unserer hervorragenden Gemeinschaft an Mozillianern und Mozillianerinnen geschrieben oder übersetzt wurden. Sie können auch jemand von ihnen werden.

+ +

Mehr erfahren about contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ + + +
    +
  1. 10 Jahre MDN
    2. +
  2. Die Geschichte des MDN
    3. +
  3. Zum MDN beitragen
    4. +
+
diff --git a/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html b/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html deleted file mode 100644 index cd5c500e41..0000000000 --- a/files/de/mdn/community/bleibe_auf_dem_laufenden/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -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 deleted file mode 100644 index f8df9274e7..0000000000 --- a/files/de/mdn/community/index.html +++ /dev/null @@ -1,80 +0,0 @@ ---- -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/howto/do_a_technical_review/index.html b/files/de/mdn/contribute/howto/do_a_technical_review/index.html deleted file mode 100644 index 0f52932293..0000000000 --- a/files/de/mdn/contribute/howto/do_a_technical_review/index.html +++ /dev/null @@ -1,54 +0,0 @@ ---- -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 deleted file mode 100644 index 2c8df95aa6..0000000000 --- a/files/de/mdn/contribute/howto/do_an_editorial_review/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -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/erstellung_eines_mdn_profils/index.html b/files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html deleted file mode 100644 index d0f017a0f1..0000000000 --- a/files/de/mdn/contribute/howto/erstellung_eines_mdn_profils/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -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/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" deleted file mode 100644 index 42a1d25435..0000000000 --- "a/files/de/mdn/contribute/howto/schlagw\303\266rter_f\303\274r_javascript_seiten/index.html" +++ /dev/null @@ -1,81 +0,0 @@ ---- -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 deleted file mode 100644 index 8c30eb2dcb..0000000000 --- a/files/de/mdn/contribute/howto/set_the_summary_for_a_page/index.html +++ /dev/null @@ -1,54 +0,0 @@ ---- -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/zu_tun_im_mdn/index.html b/files/de/mdn/contribute/zu_tun_im_mdn/index.html deleted file mode 100644 index 84ae882896..0000000000 --- a/files/de/mdn/contribute/zu_tun_im_mdn/index.html +++ /dev/null @@ -1,28 +0,0 @@ ---- -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 -translation_of_original: MDN/Contribute/Tasks ---- -
{{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/style_guide/index.html b/files/de/mdn/guidelines/style_guide/index.html deleted file mode 100644 index 274d9d4f8c..0000000000 --- a/files/de/mdn/guidelines/style_guide/index.html +++ /dev/null @@ -1,560 +0,0 @@ ---- -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/guidelines/writing_style_guide/index.html b/files/de/mdn/guidelines/writing_style_guide/index.html new file mode 100644 index 0000000000..274d9d4f8c --- /dev/null +++ b/files/de/mdn/guidelines/writing_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/kuma/beheben_von_kumascript_fehlern/index.html b/files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html deleted file mode 100644 index 0255388aa1..0000000000 --- a/files/de/mdn/kuma/beheben_von_kumascript_fehlern/index.html +++ /dev/null @@ -1,63 +0,0 @@ ---- -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 deleted file mode 100644 index 06e83f21ee..0000000000 --- a/files/de/mdn/kuma/index.html +++ /dev/null @@ -1,28 +0,0 @@ ---- -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 deleted file mode 100644 index 6aeb6703ed..0000000000 --- a/files/de/mdn/nutzer_leitfaden/index.html +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: MDN Benutzerhandbuch -slug: MDN/nutzer_leitfaden -translation_of: MDN/Tools -translation_of_original: MDN/User_guide ---- -
{{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/compatibility_tables/index.html b/files/de/mdn/structures/compatibility_tables/index.html new file mode 100644 index 0000000000..758d450e7c --- /dev/null +++ b/files/de/mdn/structures/compatibility_tables/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/structures/kompatibilitaets_tabellen/index.html b/files/de/mdn/structures/kompatibilitaets_tabellen/index.html deleted file mode 100644 index 758d450e7c..0000000000 --- a/files/de/mdn/structures/kompatibilitaets_tabellen/index.html +++ /dev/null @@ -1,500 +0,0 @@ ---- -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/tools/index.html b/files/de/mdn/tools/index.html new file mode 100644 index 0000000000..6aeb6703ed --- /dev/null +++ b/files/de/mdn/tools/index.html @@ -0,0 +1,9 @@ +--- +title: MDN Benutzerhandbuch +slug: MDN/nutzer_leitfaden +translation_of: MDN/Tools +translation_of_original: MDN/User_guide +--- +
{{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/tools/kumascript/troubleshooting/index.html b/files/de/mdn/tools/kumascript/troubleshooting/index.html new file mode 100644 index 0000000000..0255388aa1 --- /dev/null +++ b/files/de/mdn/tools/kumascript/troubleshooting/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/yari/index.html b/files/de/mdn/yari/index.html new file mode 100644 index 0000000000..06e83f21ee --- /dev/null +++ b/files/de/mdn/yari/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/\303\274ber/index.html" "b/files/de/mdn/\303\274ber/index.html" deleted file mode 100644 index 745152be79..0000000000 --- "a/files/de/mdn/\303\274ber/index.html" +++ /dev/null @@ -1,99 +0,0 @@ ---- -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" deleted file mode 100644 index 47411ecf30..0000000000 --- "a/files/de/mdn/\303\274ber/link_zu_mdn/index.html" +++ /dev/null @@ -1,82 +0,0 @@ ---- -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