From 004b3c5fc8d71b68fcb019c9e0346bf80024dbbd Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:48:47 +0100 Subject: unslug nl: move --- files/nl/mdn/about/index.html | 113 +++++ files/nl/mdn/at_ten/index.html | 39 ++ files/nl/mdn/community/conversations/index.html | 60 --- files/nl/mdn/community/index.html | 55 --- .../samenwerken_in_een_community/index.html | 102 ----- files/nl/mdn/community/whats_happening/index.html | 40 -- .../howto/aanmaken_mdn_account/index.html | 48 -- .../een_redactionele_beoordeling_geven/index.html | 57 --- .../een_technische_beoordeling_maken/index.html | 56 --- .../howto/taggen_javascript_pagina/index.html | 74 --- .../verhoogde_bevoegdheden_aanvragen/index.html | 21 - files/nl/mdn/guidelines/style_guide/index.html | 502 --------------------- .../mdn/guidelines/writing_style_guide/index.html | 502 +++++++++++++++++++++ files/nl/mdn/kuma/index.html | 27 -- .../index.html | 69 --- files/nl/mdn/over/index.html | 113 ----- .../tools/kumascript/troubleshooting/index.html | 69 +++ files/nl/mdn/tools/template_editing/index.html | 16 - files/nl/mdn/yari/index.html | 27 ++ 19 files changed, 750 insertions(+), 1240 deletions(-) create mode 100644 files/nl/mdn/about/index.html create mode 100644 files/nl/mdn/at_ten/index.html delete mode 100644 files/nl/mdn/community/conversations/index.html delete mode 100644 files/nl/mdn/community/index.html delete mode 100644 files/nl/mdn/community/samenwerken_in_een_community/index.html delete mode 100644 files/nl/mdn/community/whats_happening/index.html delete mode 100644 files/nl/mdn/contribute/howto/aanmaken_mdn_account/index.html delete mode 100644 files/nl/mdn/contribute/howto/een_redactionele_beoordeling_geven/index.html delete mode 100644 files/nl/mdn/contribute/howto/een_technische_beoordeling_maken/index.html delete mode 100644 files/nl/mdn/contribute/howto/taggen_javascript_pagina/index.html delete mode 100644 files/nl/mdn/contribute/processes/verhoogde_bevoegdheden_aanvragen/index.html delete mode 100644 files/nl/mdn/guidelines/style_guide/index.html create mode 100644 files/nl/mdn/guidelines/writing_style_guide/index.html delete mode 100644 files/nl/mdn/kuma/index.html delete mode 100644 files/nl/mdn/kuma/probleemoplossingen_kumascript_errors/index.html delete mode 100644 files/nl/mdn/over/index.html create mode 100644 files/nl/mdn/tools/kumascript/troubleshooting/index.html delete mode 100644 files/nl/mdn/tools/template_editing/index.html create mode 100644 files/nl/mdn/yari/index.html (limited to 'files/nl/mdn') diff --git a/files/nl/mdn/about/index.html b/files/nl/mdn/about/index.html new file mode 100644 index 0000000000..9af7825aab --- /dev/null +++ b/files/nl/mdn/about/index.html @@ -0,0 +1,113 @@ +--- +title: Over MDN +slug: MDN/Over +tags: + - Auteursrechten + - Collaboratie + - Community + - Documentație + - Gids + - Licenties + - MDN Meta +translation_of: MDN/About +--- +
{{MDNSidebar}}
+ +
{{IncludeSubNav("/nl/docs/MDN")}}
+ +

MDN Web Docs is een evoluerend leerplatform voor webtechnologieën en de software die het Web van zijn kracht voorziet, zoals:

+ + + +

Onze missie

+ +

MDN's missie is simpelweg ontwikkelaars de informatie bieden die ze nodig hebben om eenvoudig projecten op het open Web te creëren. Als het een open technologie is die wordt blootgesteld aan het web, willen we het documenteren.

+ +

Daarnaast bieden we documentatie over Mozillaproducten en hoe te bouwen en bij te dragen aan Mozillaprojecten.

+ +

Als u onzeker bent of een specifiek onderwerp wel of niet past  op MDN, lees dan: Hoort dit op MDN?

+ +

Hoe u kunt helpen

+ +

U hoeft niet te kunnen coderen—of goed kunnen schrijven—om MDN te kunnen helpen! We hebben vele manieren waarop men kan helpen, van het beoordelen van artikelen om er zeker van te zijn dat ze logisch zijn, tot het bijdragen van tekst en het toevoegen van voorbeeldcode. In feite zijn er zoveel manieren om te helpen dat we een pagina, genaamd Beginnen op MDN, hebben die u helpt een taak te kiezen, gebaseerd op uw interesses en hoeveel tijd u hebt!

+ +

U kunt ook helpen door het promoten van MDN op uw eigen blog of website.

+ +

De MDN-gemeenschap

+ +

Onze gemeenschap is een wereldwijde! We hebben geweldige bijdragers over de hele wereld, in verschillende talen. Als u meer wilt weten over ons, of als u hulp nodig hebt met MDN op welke manier dan ook, neem dan gerust een kijkje op ons discussieforum of IRC-kanaal! U kunt ook bijhouden wat we doen door ons Twitter-account te volgen, @MozDevNet. U kunt ook tweets naar ons verzenden als u ziet dat er iets verkeerd is, of als u feedback wilt geven (of bedankjes) aan onze schrijvers en bijdragers!

+ +

De inhoud van MDN Web Docs gebruiken

+ +

Auteursrechten en licenties

+ +

MDN's wikidocumenten zijn opgesteld met de bijdragen van vele auteurs, zowel binnen als buiten de Mozilla Foundation. Tenzij anders aangegeven, is de inhoud beschikbaar onder de voorwaarden van de Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 of een latere versie. Schrijf "Mozilla-bijdragers" toe en voeg een hyperlink (online) of URL (in gedrukte vorm) toe aan de specifieke wikipagina voor de inhoud die wordt aangekocht. Als u bijvoorbeeld een toeschrijving voor dit artikel wilt geven, kunt u schrijven:

+ +
Over MDN door Mozilla Bijdragers is onder licentie van CC-BY-SA 2.5.
+ +

"Mozilla Bijdragers" verwijst naar de geschiedenis van de geciteerde pagina. Zie Best practices for attribution voor verdere uitleg.

+ +
+

Zie MDN content op WebPlatform.org voor informatie over hoe u MDN-inhoud op die site kunt hergebruiken en toeschrijven.

+
+ +

Codevoorbeelden die zijn toegevoegd voor 20 augustus 2010, zijn beschikbaar onder de MIT-licentie; U moet de volgende attributie-informatie in het MIT-sjabloon zetten: "© <datum van laatste herziening van de wikipagina> <naam van de persoon die het in de wiki heeft geplaatst>".

+ +

Codevoorbeelden toegevoegd op of na 20 augustus 2010 zijn in het publiek domein. Er is geen licentie nodig, maar als er een nodig is, kunt u de volgende gebruiken: "Alle auteursrechten zijn opgedragen aan het publiek domein. http://creativecommons.org/publicdomain/zero/1.0/".

+ +

Als u een bijdrage wilt leveren aan deze wiki, moet u uw documentatie beschikbaar maken onder de Attribution-ShareAlike-licentie (of soms een alternatieve licentie die al is opgegeven door de pagina die u aan het bewerken bent) en uw codevoorbeelden beschikbaar maken onder Creative Commons CC-0 (een publiek-domeinaanduiding). Door bij te dragen aan deze wiki, stemt u ermee in dat uw bijdragen onder die licenties beschikbaar worden gesteld.

+ +

Sommige oudere inhoud was beschikbaar gemaakt onder een andere licentie dan hierboven genoteerd; deze staan onderaan elke pagina genoteerd aan de hand van een Alternatief licentieblok.

+ +
+

Er mogen geen nieuwe pagina's gemaakt worden met andere licenties.

+
+ +

Auteursrecht voor ingebrachte materialen blijft bij de auteur, tenzij de auteur het aan iemand anders toewijst.

+ +

Als u vragen of opmerkingen hebt over alles wat hier wordt besproken, neem dan contact op met Eric Shepherd.

+ +
+

De rechten op de handelsmerken, logo's, servicemerken van de Mozilla Foundation en het uiterlijk van deze website zijn niet gelicentieerd onder de Creative Commons-licentie en voor zover het werken van auteurschap betreft (zoals logo's en grafische afbeeldingen) ontwerp), zijn ze niet opgenomen in het werk dat onder die voorwaarden is gelicentieerd. Als u de tekst van documenten gebruikt en tevens een van deze rechten wilt gebruiken, of als u andere vragen hebt over het voldoen aan onze licentievoorwaarden voor deze verzameling, dient u hier contact op te nemen met de Mozilla Foundation: licensing@mozilla.org.

+ + + +

Linken naar MDN

+ +

Zie dit artikel voor begeleiding op linken naar MDN voor de beste uitvoeringen bij het linken.

+ + + + + +

Downloaden van content

+ +

U kunt een volledige tarball mirror van MDN downloaden (2.1 GB vanaf februari 2017).

+ +

Enkele pagina's

+ +

U kunt de inhoud van één pagina op MDN ophalen door documentparameters toe te voegen aan de URL om op te geven welke indeling u wilt.

+ +

Third-party tools

+ +

U kunt MDN content bekijken via third-party tools zoals Dash (voor Mac OS) en Zeal (voor Linux en Windows).

+ +

Kapeli publiceert ook offline MDN docs over HTML, CSS, JavaScript, SVG, en XSLT.

+ +

Problemen rapporteren met MDN Web Docs

+ +

Zie Hoe rapporteert men een probleem op MDN.

+ +

Geschiedenis van MDN Web Docs

+ +

Het MDN Web Docs (voorheen Mozilla Developer Network (MDN), voorheen Mozilla Developer Center (MDC), a.k.a. Devmo) project startte begin 2005, toen de Mozilla Foundation Een licentie van AOL verkreeg om de originele Netscape DevEdge content te gebruiken. De DevEdge-inhoud werd gedolven voor nog bruikbaar materiaal, dat vervolgens door vrijwilligers werd gemigreerd naar deze wiki, zodat het gemakkelijker te updaten en onderhouden was.

+ +

U kunt meer geschiedenis van MDN vinden op onze 10-jarig jubileum-pagina, inclusief een mondelinge geschiedenis door enkele van de mensen die erbij betrokken waren.

+ +

Over Mozilla

+ +

Of u nu meer wilt weten over wie we zijn, hoe u een deel van Mozilla kunt zijn of waar u ons kunt vinden, u bent hier aan het juiste adres. Als u wilt weten wat ons drijft en ons anders maakt, bezoek dan onze missiepagina.

diff --git a/files/nl/mdn/at_ten/index.html b/files/nl/mdn/at_ten/index.html new file mode 100644 index 0000000000..f1bd6ea3b7 --- /dev/null +++ b/files/nl/mdn/at_ten/index.html @@ -0,0 +1,39 @@ +--- +title: MDN at 10 +slug: MDN_at_ten +tags: + - Geschiedenis +translation_of: MDN_at_ten +--- + + +
+
+

De geschiedenis van MDN

+ +

In het begin van 2005, zette een klein team van idealisten het plan op om een nieuwe, vrije, door de gemeenschap gemaakte, online hulpbron voor alle Webontwikkelaars te maken. Hun brilliante, maar ongewone idee is uitgegroeid tot het Mozilla Developer Network van vandaag, de voornaamste hulpbron voor alle open Web technologieën. Tien jaar later is onze wereldwijde gemeenschap groter dan ooit, en samen maken we nog altijd documentatie, voorbeeldcode and leermiddelen voor alle open Web technologieën, zoals CSS, HTML, JavaScript en alle andere dingen die het open Web zo krachtig maken.

+ +

Meer weten about the history

+ + +

Bijdragen tot MDN

+ +

Gedurende tien jaar heeft de MDN gemeenschap het open Web gedocumenteerd. Van het corrigeren van simpele typefouten tot het schrijven van een volledige documentatie voor een nieuwe API, iedereen heeft iets te bieden en geen bijdrage is te groot of te klein. We hebben meer dan 90,000 pagina's die geschreven of vertaald werden door leden van onze voortreffelijke gemeenschap van Mozillians. U kunt een van hen worden.

+ +

Meer weten about contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ + + +
    +
  1. MDN at 10
  2. +
  3. De geschiedenis van MDN
  4. +
  5. Bijdragen tot MDN
  6. +
+
diff --git a/files/nl/mdn/community/conversations/index.html b/files/nl/mdn/community/conversations/index.html deleted file mode 100644 index e1319c3259..0000000000 --- a/files/nl/mdn/community/conversations/index.html +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: MDN-gemeenschapsgesprekken -slug: MDN/Community/Conversations -tags: - - Gemeenschap - - Gids - - MDN Meta -translation_of: MDN/Community/Conversations ---- -
{{MDNSidebar}}

Het ‘werk’ van MDN gebeurt op de MDN-website, maar de ‘gemeenschap’ bestaat ook door middel van (asynchrone) discussie en (synchrone) online chat en bijeenkomsten.

- -

Asynchrone discussies

- -

Voor het delen van informatie en het hebben van lopende discussies heeft MDN zijn eigen categorie (‘MDN’) op het Discourse-forum van Mozilla. Deze categorie kan worden gebruikt voor alle onderwerpen die zijn gerelateerd aan MDN, zoals de creatie, vertaling en het onderhoud van documentatie-inhoud, de ontwikkeling van het MDN-platform en zaken als plannen, doelen stellen en het bewaken van de voortgang.

- - - -

Historische archieven

- -

Voor juni 2017 vonden MDN-gerelateerde discussies plaats in mailinglijsten die toegankelijk werden gemaakt en werden gearchiveerd met Google-groepen. Als u in deze afgelopen discussies wil zoeken, kunt u kijken naar de Google-groepen die met de oude mailinglijsten corresponderen. (Ja, we weten dat deze namen overlappen en verwarrend zijn. Historisch ongeluk. Sorry hiervoor.)

- -
-
mozilla.dev.mdc alias dev-mdc
-
Deze lijst was voor discussies over documentatie-inhoud op MDN.
-
mozilla.dev.mdn alias dev-mdn
-
Deze lijst was voor ontwikkelwerk van het onderliggende platform van MDN, genaamd Kuma.
-
mozilla.mdn alias mdn@
-
Dit forum was voor discussies over planning en prioritering op een hoger niveau, voor de MDN-website en andere gerelateerde initiatieven.
-
- -

 

- -

Chat in IRC

- -

 

- -

Internet Relay Chat (IRC) is de methode waaraan we de voorkeur geven voor dagelijkse chat en real-time discussies tussen gemeenschapsleden. We gebruiken een aantal kanalen op de server irc.mozilla.org voor discussies die aan MDN zijn gerelateerd.

- -
-
#mdn
-
Dit kanaal is ons voornaamste kanaal voor het bespreken van de inhoud van MDN. We praten over schrijven, het organiseren van inhoud, enzovoort. We hebben hier ook onze ‘koffieautomaatgesprekken’ – het is een manier waarop de gemeenschap contact kan houden en kan samenkomen. Dit is ook de plek om over andere aspecten van MDN te praten (anders dan de ontwikkeling van het platform), zoals Demo Studio, profielen, enzovoort.
-
#mdndev
-
In dit kanaal komen de leden van ons ontwikkelteam – de mensen die de code schrijven waarmee MDN werkt – samen en bespreken ze hun dagelijkse werk. U bent welkom om deel te nemen en mee te doen met het ontwikkelen of vragen te stellen over problemen met de software die u ziet.
-
- -

Deze kanalen zijn waarschijnlijk het meest actief tijdens doordeweekse dagen in Noord-Amerika.

- -

Het kan zijn dat u meer over IRC wilt leren en een installeerbare IRC-client zoals ChatZilla wilt gebruiken. Het is geïmplementeerd als een add-on voor Firefox, waardoor het makkelijk is te installeren en gebruiken. Als u niet bekend bent met IRC, is deelnemen door gebruik van een webgebaseerde IRC-client zoals Mibbit een makkelijke manier. Hier vindt u directe koppelingen naar de kanalen #mdn en #mdndev op Mibbit.

- -

Neem deel aan onze bijeenkomsten (en andere evenementen)

- -

Het MDN-team houdt regelmatig een aantal bijeenkomsten dat open is voor de MDN-gemeenschap. Bekijk de pagina MDN-bijeenkomsten op de wiki van Mozilla voor details over het rooster, de agenda’s en notulen, en informatie over hoe u kunt deelnemen.

- -

Bekijk de evenementenkalender van MDN voor deze en andere bijeenkomsten, lokale bijeenkomsten en andere evenementen. De terugkerende bijeenkomsten worden samengevat op de wiki-pagina MDN-bijeenkomsten.

- -

Als u een bijeenkomst ziet die plaatsvindt in het kanaal ‘mdn’ op uw Vidyo-videoconferentiesysteem, kunt u het gesprek bijwonen via internet.

diff --git a/files/nl/mdn/community/index.html b/files/nl/mdn/community/index.html deleted file mode 100644 index 7856783b88..0000000000 --- a/files/nl/mdn/community/index.html +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Deelnemen aan de MDN-gemeenschap -slug: MDN/Community -tags: - - Community - - Gemeenschap - - Handleiding - - Landing - - MDN Meta -translation_of: MDN/Community ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/nl/docs/MDN")}}
- -
-

MDN Web Docs is meer dan een wiki: het is een gemeenschap van ontwikkelaars die samenwerken om MDN een uitstekende bron te maken voor ontwikkelaars die open-source technologieën gebruiken.

-
- -

We zouden graag zien dat u aan MDN bijdraagt, maar we zien nog liever dat u aan de MDN-gemeenschap deelneemt. U kunt als volgt verbonden raken, in drie eenvoudige stappen:

- -
    -
  1. Maak een MDN-account aan.
  2. -
  3. Neem deel aan conversaties.
  4. -
  5. Volg wat er gebeurt.
  6. -
- -

Hoe de gemeenschap werkt

- -

De volgende artikelen beschrijven een aantal mogelijkheden in de gemeenschap van MDN.

- -
-
-
-
Rollen binnen de gemeenschap
-
Er is een aantal rollen binnen de MDN-gemeenschap dat bepaalde verantwoordelijkheden met zich meedraagt.
-
Doc sprints
-
Dit is een handleiding voor het organiseren van een documentatiesprint. Deze bevat advies en tips van mensen die docsprints hebben georganiseerd, met de bedoeling om u er ook een te helpen organiseren.
-
Blijf op de hoogte
-
MDN wordt u aangeboden door de Mozilla Developer Network Community. Hier vindt u wat manieren waarop we informatie delen over wat we doen.
-
- -
-
-
- -
-
-
MDN gemeenschapsdiscussies
-
Het ‘werk’ van MDN vindt plaats op de website van MDN, maar de ‘gemeenschap’ bestaat ook uit (asynchrone) discussies en (synchrone) onlinechat en -meetings.
-
Werken in de gemeenschap
-
Een groot deel van het op grote schaal bijdragen aan MDN documentatie is weten hoe u als onderdeel van de MDN-gemeenschap kunt werken. Dit artikel biedt tips om de communicatie tussen en naar andere schrijvers en ontwikkelteams zo efficiënt mogelijk te laten verlopen.
-
-
-
diff --git a/files/nl/mdn/community/samenwerken_in_een_community/index.html b/files/nl/mdn/community/samenwerken_in_een_community/index.html deleted file mode 100644 index a2256cf365..0000000000 --- a/files/nl/mdn/community/samenwerken_in_een_community/index.html +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Samenwerken in een community -slug: MDN/Community/Samenwerken_in_een_community -translation_of: MDN/Community/Working_in_community ---- -
{{MDNSidebar}}
- -

Een groot onderdeel van de bijdrages van MDN documentaties op grote schaal, is het samenwerken en de communicatie in een community. Dit artikel geeft tips om interacties tussen schrijvers en ontwikkelteams beter te maken.

- -

Algemene gedragscodes

- -

Hier zijn een paar algemene gedragscodes wanneer men werkt in de Mozilla Community.

- - - -

Be tactful

- -

Always be tactful and respectful when communicating with others.

- -

Politely pointing out mistakes

- -

If your purpose in contacting someone is to ask them to do something differently, or to point out a mistake they've been making (especially if they repeatedly do it), start your message with a positive comment. This softens the blow, so to speak, and it demonstrates that you're trying to be helpful, rather than setting you up as the  bad guy.

- -

For example, if a new contributor has been creating lots of pages without tags, and you'd like to point out this problem, your message to them might look like this (the stuff you'd need to change for each case us underlined):

- -
-

Hi, MrBigglesworth, I've been noticing your contributions to the Wormhole API documentation, and it's fantastic to have your help! I particularly like the way you balanced your level of detail with readability. That said, though, you could make these articles even better and more helpful if you added the correct tags to the pages as you go.

- -

See the MDN tagging guide (https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Tag) for details.

- -

Thanks again, and I look forward to your future contributions!

-
- -

Sharing knowledge

- -

As you participate in the MDN project, it's useful to know what's going on, and to interact with other members of our community. By talking with others in our community, you can get—and share—ideas, status updates, and more. We also have tools and informational resources that can help you know what's being done, by whom.

- -

Communication channels

- -

There are several ways you can engage with community members (either developers or writers), each of which has some of its own particular rules of etiquette.

- -

Bugzilla

- -

When writing documentation to cover changes implemented as a result of a bug in Bugzilla, you'll often interact with people involved in those bugs. Be sure to keep the Bugzilla Etiquette guide in mind at all times!

- -

Email

- -

Sometimes, a private email exchange between you and one or more other people is the way to go, if you have their email address.

- -
-

Note: As a general rule, if someone has posted their email address on documents about the technology you're documenting, has given you their email address personally, or generally has a well-known email address, email is an acceptable "first contact" approach. If you have to dig for it, you probably should try to get permission in IRC or a mailing list first, unless you've exhausted all other attempts at getting in touch.

-
- -

Content status tools

- -

We have several useful tools that provide information about the status of documentation content.

- -
-
Revision dashboard
-
The revision dashboard provides a fantastic tool to review changes made to MDN content. You can see recent history, choose a range of time to view, and filter based on things like locale, contributor's name, and topic. Once you're looking at a set of revisions, you can view the changes made in each revision, quickly open the page, see a full history, or even revert the changes (if you have those privileges).
-
Documentation status overview
-
Our documentation status overview page provides a list of all the areas of MDN that have been configured for status tracking, with information about how many pages therein need different types of work done. Click through to a particular topic area to see detailed lists of content that needs work, such as pages that have no tags, or are tagged with indicators that certain types of work need to be done. You can even see lists of pages that haven't been updated in a long time and may be out of date, as well as a list of bugs that have been flagged as impacting the documentation in that area.
-
Documentation project plans
-
We have a number of writing projects that are in the planning stages, or are large and ongoing, for which we have written planning documents to help us keep track of what we need to get done.
-
MDN Trello board
-
The MDN staff writers use a Trello board to manage current and future documentation projects. You can take a look to see what we're doing and how it's going, and you can see what projects we'd like to see happen soon. Some of those will be taken on by staff writers, but you should feel free to take one over if you like! For more information about how this board is used and how you can use it, you can read this page.
-
- -

The development community

- -

Possibly the most important relationships to develop and maintain, as a member of the MDN writing community, are those you develop and sustain with the developers. They create the software we're developing, but they're also the most useful source of information we have. It's crucial that we maintain good relations with developers—the more they like you, the more likely they are to answer your questions quickly, accurately, and thoroughly!

- -

In addition, you represent the MDN writing community. Please help ensure we keep our excellent working relationship with the dev team by making every interaction they have with the writing team be a good one.

- -

On a related note, a great way to find the right person to talk to is to look at the module owners lists.

- -

The writing community

- -

The writing community is a large one. While the number of extremely frequent, or large-scale contributors is relatively small, there are many dozens or hundreds of people who contribute at least now and then. Fortunately, these are by and large awesome people with a genuine love of the Web, Mozilla, and/or documentation, and interacting with them is almost always pretty easy.

- -

See the article Join the community for more information about the MDN community.

- -

The most frequent place you'll directly interact with other writers is in the {{IRCLink("mdn")}} channel on IRC. This channel is specifically reserved for discussing documentation. For IRC-specific etiquette tips, see the Mozilla Support article "Getting Started with IRC." You'll also have discussions with us on the MDN discussion forum. In general, IRC tends to be used for quick, more in-person-like discussions, while the mailing list is typically used for longer-duration conversation.

- -

By keeping in mind the {{anch("General etiquette guidelines")}}, you'll find that usually things go very smoothly.

- -

Zie ook

- - diff --git a/files/nl/mdn/community/whats_happening/index.html b/files/nl/mdn/community/whats_happening/index.html deleted file mode 100644 index d3daf3b9df..0000000000 --- a/files/nl/mdn/community/whats_happening/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Blijf op de hoogte -slug: MDN/Community/Whats_happening -tags: - - Beginner - - Gemeenschap - - Gids - - MDN Meta -translation_of: MDN/Community/Whats_happening ---- -
{{MDNSidebar}}

MDN wordt mede mogelijk gemaakt door de MDN-gemeenschap. Hier is een aantal manieren waarop we informatie delen over wat we doen.

- -

Blogs

- -
-
Mozilla Hacks
-
Nieuws over en uitgebreide dekking van web- en Mozillatechnologieën en functies.
-
Engaging Developers
-
Het promoten van activiteiten en discussies omtrent de gemeenschap die betrokken is bij MDN van Mozilla.
-
- -

Streams of ephemera

- - - -

Statusboards en dashboards

- -

Bekijk de documentatiestatuspagina's om te zien wat er gebeurt over de volledige breedte van de MDN-inhoud. U kunt zien welke artikelen moeten worden geschreven of bijgewerkt, welke onderwerpen de meeste hulp nodig hebben, en nog veel meer.

- -

MDN-bijeenkomsten

- -

Er is een aantal vaste bijeenkomsten voor het bijhouden en delen van voortgang binnen verschillende MDN-gerelateerde projecten en processen. Ze staan beschreven op de wikipagina voor MDN-bijeenkomsten.

- -

Om een idee te krijgen van wat er gebeurt, is de MDN gemeenschapsbijeenkomst de beste bijeenkomst om bij te wonen. Deze bijeenkomst vindt elke twee weken plaats op woensdag, 10:00 US Pacific time (UTC-0800 Oktober-Maart, UTC-0700 in Maart-Oktober), in het #mdn IRC-kanaal. Bekijk de wikipagina voor MDN-bijeenkomsten voor agenda's en notulen van de vorige bijeenkomsten.

- -

De agenda voor openbare MDN-evenementen bevat gemeenschapsbijeenkomsten van MDN, doc sprints en andere MDN-gerelateerde evenementen. Als u een bijeenkomst ziet die plaatsvindt in het "mdn"-kanaal op uw Vidyo videoconferentiesysteem kunt u het gesprek bijwonen via internet.

diff --git a/files/nl/mdn/contribute/howto/aanmaken_mdn_account/index.html b/files/nl/mdn/contribute/howto/aanmaken_mdn_account/index.html deleted file mode 100644 index cc50327400..0000000000 --- a/files/nl/mdn/contribute/howto/aanmaken_mdn_account/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Een account op MDN aanmaken -slug: MDN/Contribute/Howto/Aanmaken_MDN_account -tags: - - Aanmelden - - Beginner - - Documentație - - Gids - - GitHub - - Profiel -translation_of: MDN/Contribute/Howto/Create_an_MDN_account ---- -
{{MDNSidebar}}

Om wijzigingen aan te brengen in de inhoud van MDN is een MDN-profiel nodig. Voor het lezen van en zoeken in de MDN-documentatie hebt u geen profiel nodig. Deze gids helpt u om uw MDN-profiel aan te maken.

- -
-
-

Waarom heeft MDN mijn e-mailadres nodig?

- -

Het e-mailadres wordt gebruik om uw account te herstellen. Indien nodig kan het beheer van MDN contact met u opnemen over uw account of uw activiteit op de site.

- -

Daarnaast kunt u zich aanmelden voor notificaties (bijvoorbeeld wanneer bepaalde pagina's worden aangepast) en berichten (bijvoorbeeld als u zich hebt aangemeld voor het beta-testteam en u nieuwe e-mails wilt ontvangen over nieuwe functies die moeten worden getest).

- -

Het e-mailadres wordt nooit getoond op MDN en wordt alleen gebruikt overeenkomstig ons privacybeleid.

- -

 

- -
U ontvangt geen berichten of notificaties van MDN als u inlogt op MDN via GitHub en u daar een "noreply"-e-mailadres gebruikt.
-
-
- -
    -
  1. Op MDN bevindt zich bovenaan elke pagina een knop Aanmelden met. Door de muisaanwijzer erboven te houden (of door hem aan te raken op een mobiel toestel) verschijnt er een lijst met authenticatiemethoden die worden ondersteund door MDN.
  2. -
  3. Selecteer een methode om in te loggen. Op dit moment is alleen GitHub beschikbaar. Als u GitHub selecteert, zal een link naar uw profiel op GitHub worden weergegeven op uw openbare profielpagina op MDN.
  4. -
  5. Volg de aanwijzingen van GitHub om uw account te verbinden met MDN.
  6. -
  7. Als de authenticatiedienst u laat terugkeren naar MDN, wordt u gevraagd om een gebruikersnaam en een e-mailadres in te voeren. De gebruikersnaam wordt openbaar getoond om u te prijzen voor uw werk. Gebruik geen e-mailadres als gebruikersnaam.
  8. -
  9. Klik Creëer mijn MDN-profiel.
  10. -
  11. Als het e-mailadres dat u hebt ingevoerd bij stap 4 niet hetzelfde is als het e-mailadres dat u gebruikt bij de authenticatiedienst, controleer dan uw e-mail en klik op de link in de bevestigings-e-mail die we u sturen.
  12. -
- -

Dat is alles! U hebt nu een MDN account en kunt onmiddellijk beginnen met het bewerken van pagina's!

- -

U kunt bovenaan elke pagina van MDN klikken op uw naam om uw openbaar profiel te zien. Daar vandaan kunt u op Bewerken klikken om uw profiel te veranderen of iets toe te voegen aan uw profiel..

- -

 

- -
-

Nieuwe gebruikersnamen mogen geen spaties of het karakter "@" bevatten. Denk eraan dat uw gebruikersnaam openbaar wordt getoond om u te prijzen voor uw werk.

-
diff --git a/files/nl/mdn/contribute/howto/een_redactionele_beoordeling_geven/index.html b/files/nl/mdn/contribute/howto/een_redactionele_beoordeling_geven/index.html deleted file mode 100644 index 38785c1f26..0000000000 --- a/files/nl/mdn/contribute/howto/een_redactionele_beoordeling_geven/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Een redactionele beoordeling geven -slug: MDN/Contribute/Howto/Een_redactionele_beoordeling_geven -tags: - - Documentație - - Gids - - Hoe kan ik - - MDN-Meta - - Redactionele beoordeling -translation_of: MDN/Contribute/Howto/Do_an_editorial_review ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/nl/docs/MDN")}}
- -

Redactionele beoordelingen bestaan uit het corrigeren van typefouten en spelling, grammatica, gebruik of tekstuele fouten in een artikel. U hoeft geen taalexpert te zijn om waardevolle bijdragen te doen aan de technische documentatie van MDN, maar artikelen hebben nog steeds controlewerk en moeten worden proefgelezen. Dit wordt in een redactionele beoordeling gedaan.

- -

Dit artikel beschrijft hoe u een redactionele beoordeling kunt geven, wat ervoor zorgt dat de inhoud op MDN accuraat is.

- -
-
Wat houdt de taak in?
-
Controlewerk (‘copy-editing’) en proeflezen (‘proof-reading’) van artikelen die zijn gemarkeerd als artikelen die een redactionele beoordeling nodig hebben.
-
Waar dient dit te worden gedaan?
-
Binnen bepaalde artikelen die zijn gemarkeerd als artikelen die een redactionele beoordeling nodig hebben.
-
Wat dient u te weten om de taak te vervullen?
-
U dient goede vaardigheden op het gebied van Nederlandse grammatica en spelling te hebben. Een redactionele beoordeling zorgt ervoor dat de grammatica, spelling en het woordgebruik juist en logisch zijn, en dat de MDN-schrijfstijlgids wordt gevolgd.
-
Wat zijn de stappen om dit te doen?
-
-
    -
  1. Kies een artikel voor beoordeling: -
      -
    1. Ga naar de lijst van artikelen die een redactionele beoordeling nodig hebben. Deze vermeldt alle pagina’s waarvoor een redactionele beoordeling is aangevraagd.
    2. -
    3. Klik op het artikel om de pagina te laden.
      - Merk op: Deze lijst wordt automatisch maar niet regelmatig gegenereerd, waardoor er artikelen in de lijst verschijnen die geen redactionele beoordeling meer nodig hebben. Als het artikel dat u hebt geselecteerd geen vak weergeeft waarin 'Dit artikel heeft een redactionele beoordeling nodig' staat, sla het artikel dan over en kies een andere.
    4. -
    5. Klik op de artikelkoppeling om de pagina te laden.
    6. -
    -
  2. -
  3. Lees het artikel en let goed op typefouten, spelling, grammatica of gebruiksfouten. Aarzel niet om naar een andere pagina te gaan als de eerste die u koos niet geschikt voor u is.
  4. -
  5. Als er geen fouten zijn, hoeft u het artikel niet te bewerken om het als beoordeeld te markeren. Zoek naar het veld voor ‘snelle beoordeling’ in de linkerzijbalk van de pagina:
    - Schermafbeelding van het zijbalkveld voor het beoordelingsverzoek
  6. -
  7. Deselecteer het vakje Redactioneel en klik op Opslaan.
  8. -
  9. Als u fouten vindt die dienen te worden gecorrigeerd: -
      -
    1. Klik boven in de pagina op de knop Bewerken; dit brengt u naar de MDN-editor.
    2. -
    3. Corrigeer eventuele typefouten en spelling, grammatica of gebruiksfouten die u tegenkomt. U hoeft niet alles te corrigeren om nuttig te zijn, maar zorg ervoor dat het verzoek voor redactionele beoordeling actief blijft als u niet helemaal zeker weet of u een volledige controle van het hele artikel hebt gedaan.
    4. -
    5. Voer onder in het artikel een Revisieopmerking in; zoiets als ‘Redactionele beoordeling: typefouten, grammatica en spelling gecorrigeerd’. Dit laat andere medewerkers en website-editors weten wat u hebt gewijzigd en waarom.
    6. -
    7. Deselecteer het vakje Redactioneel onder Beoordeling nodig? Dit bevindt zich net onder de sectie Revisieopmerking van de pagina.
    8. -
    9. Klik op de knop Publiceren.
    10. -
    -
  10. -
- -
-

Mogelijk zijn uw wijzigingen niet meteen zichtbaar na het opslaan; er kan een vertraging zijn bij het verwerken en opslaan van de pagina.

-
-
-
diff --git a/files/nl/mdn/contribute/howto/een_technische_beoordeling_maken/index.html b/files/nl/mdn/contribute/howto/een_technische_beoordeling_maken/index.html deleted file mode 100644 index 119e15a9d2..0000000000 --- a/files/nl/mdn/contribute/howto/een_technische_beoordeling_maken/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Een technische beoordeling geven -slug: MDN/Contribute/Howto/Een_technische_beoordeling_maken -tags: - - Beoordeling - - Documentație - - Gids - - MDN Meta -translation_of: MDN/Contribute/Howto/Do_a_technical_review ---- -
{{MDNSidebar}}
{{IncludeSubnav("/nl/docs/MDN")}}
- -

Een technische beoordeling bestaat uit het beoordelen van de technische nauwkeurigheid en volledigheid van een artikel, en het corrigeren hiervan als het nodig is. Als een schrijver van een artikel iemand anders wil vragen om de technische inhoud van een artikel te controleren, klikt diegene op het vakje met de naam 'Technische beoordeling' tijdens het bewerken. Vaak neemt een schrijver contact op met een specifieke technicus om de tekst te laten beoordelen, maar iedereen met technische kennis kan dit doen.

- -

Dit artikel beschrijft hoe een technische beoordeling kan worden gedaan, die helpt te zorgen dat de inhoud op MDN nauwkeurig is.

- -
-
Wat is de taak?
-
Het beoordelen en corrigeren van artikelen op technische nauwkeurigheid en volledigheid.
-
Waar moet dit worden gedaan?
-
In specifieke artikelen die zijn gemarkeerd als het behoeven van een technische beoordeling.
-
Wat moet u weten om de taak te kunnen uitvoeren?
-
-
    -
  • Vakkundige kennis over het onderwerp van het artikel dat u beoordeelt. Als het lezen van het artikel u geen nieuwe kennis bijbrengt, kunt u zichzelf beschouwen als een expert.
  • -
  • Hoe u een wiki-artikel op MDN kunt bewerken.
  • -
-
-
Stappenplan
-
-
    -
  1. Kies een artikel om te beoordelen: -
      -
    1. Ga naar de lijst met pagina's die een technische beoordeling nodig hebben. Op deze lijst staan alle pagina's waar technische beoordelingen voor zijn aangevraagd.
    2. -
    3. Kies een pagina met een onderwerp waar u bekend mee bent.
    4. -
    5. Klik op het artikel om de pagina te laden.
    6. -
    -
  2. -
  3. Lees het artikel, waarbij u goed let op de technische details: Is het artikel correct? Mist er iets? Aarzel niet om naar een andere pagina te gaan als de eerste die u koos niet bij u past.
  4. -
  5. Als er geen fouten zijn hoeft u het artikel niet te bewerken om het als beoordeeld te markeren. Zoek naar het vak 'snelle beoordeling' aan de linkerkant van de pagina. Dit gele vak geeft alle beoordelingen weer die in behandeling zijn. Hier kunt u een beoordeling als voltooid markeren. Als er om een technische beoordeling is gevraagd, ziet dat er als volgt uit:
    - Screenshot  van een vak aan de linkerkant van de pagina, waarin de beoordelingen staan die moeten worden uitgevoerd en waar markeringen kunnen worden gewijzigd.
  6. -
  7. Verwijder de selectie van het vakje Technisch en klik op Opslaan.
  8. -
  9. Als u fouten vindt die moeten worden gecorrigeerd is het ook mogelijk om de status van de beoordelingsaanvraag te wijzigen in de editor. U kunt dat als volgt doen: -
      -
    1. Klik op de knop Bewerken bovenaan de pagina om de pagina te bewerken. Hiermee gaat u naar de editor van MDN.
    2. -
    3. Herstel alle informatie die niet correct is, en/of voeg belangrijke informatie toe die mist.
    4. -
    5. Vul een revisieopmerking onderaan het artikel. Dit is een kort bericht dat beschrijft wat u hebt gedaan, zoals 'Technische beoordeling voltooid.' Als u informatie hebt gecorrigeerd, kunt u dat noemen in uw opmerking, bijvoorbeeld 'Technische beoordeling en parameterbeschrijvingen hersteld.' Hierdoor weten andere medewerkers en websitebewerkers wat u hebt gewijzigd en waarom. U kunt ook noemen of er specifieke stukken waren waarvoor u zich niet deskundig genoeg voelde om het te beoordelen.
    6. -
    7. Verwijder de selectie van het vakje Technisch onder Beoordeling nodig? onder het gedeelte van de pagina waarin u een revisieopmerking kunt schrijven.
    8. -
    9. Klik op de knop Publiceren.
    10. -
    -
  10. -
- -

Gefeliciteerd! U hebt uw eerste technische beoordeling gedaan! Bedankt voor uw hulp!

-
-
diff --git a/files/nl/mdn/contribute/howto/taggen_javascript_pagina/index.html b/files/nl/mdn/contribute/howto/taggen_javascript_pagina/index.html deleted file mode 100644 index ce57acb2f4..0000000000 --- a/files/nl/mdn/contribute/howto/taggen_javascript_pagina/index.html +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: JavaScript-pagina’s taggen -slug: MDN/Contribute/Howto/Taggen_JavaScript_pagina -tags: - - Guide - - Howto - - JavaScript - - MDN Meta -translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages ---- -
{{MDNSidebar}}

Taggen bestaat uit het toevoegen van meta-informatie aan pagina’s, zodat gerelateerde inhoud kan worden gegroepeerd, bijvoorbeeld in het zoekhulpmiddel.

- -
-
Waar moet dit worden gedaan?
-
Binnen specifieke JavaScript-gerelateerde pagina’s zonder labels.
-
Wat dient u te weten om de taak uit te voeren?
-
Basiskennis over programmeren met JavaScript, zoals weten wat een methode of een eigenschap is.
-
Wat zijn de stappen om het te doen?
-
-
    -
  1. Kies een van de pagina’s in de lijst hierboven.
  2. -
  3. Klik op de artikelkoppeling om de pagina te laden.
  4. -
  5. Klik zodra de pagina is geladen op de knop BEWERKEN bovenaan het artikel; hierdoor komt u in de MDN-editor.
  6. -
  7. Op zijn minst dient het label JavaScript te worden toegevoegd. Mogelijke andere labels om toe te voegen zijn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    LabelPagina’s om het op te gebruiken
    Method (Methode)methoden
    Property (Eigenschap)eigenschappen
    prototype (prototype)prototypen
    Object type name (type objectnaam)methoden van een object; String.vanCharCode dient bijvoorbeeld het label String te bevatten.
    ECMAScript6 en Experimental (ECMAScript6 en experimenteel)functies toegevoegd in een nieuwe ECMAScript-versie
    Deprecated (afgeschaft)afgeschafte functies (waarvan het gebruik wordt afgeraden, maar die nog steeds worden ondersteund)
    Obsolete (verouderd)verouderde functies (die niet meer in moderne browsers worden ondersteund)
    others (andere)Zie MDN-labelstandaarden voor andere mogelijke labels die kunnen worden toegepast
    -
  8. -
  9. Sla het artikel op met een opmerking.
  10. -
  11. U bent klaar!
  12. -
-
-
- -

 

diff --git a/files/nl/mdn/contribute/processes/verhoogde_bevoegdheden_aanvragen/index.html b/files/nl/mdn/contribute/processes/verhoogde_bevoegdheden_aanvragen/index.html deleted file mode 100644 index f7f085ae5b..0000000000 --- a/files/nl/mdn/contribute/processes/verhoogde_bevoegdheden_aanvragen/index.html +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Verhoogde bevoegdheden aanvragen -slug: MDN/Contribute/Processes/Verhoogde_bevoegdheden_aanvragen -tags: - - Gids - - MDN Meta - - Processen -translation_of: MDN/Contribute/Processes/Requesting_elevated_privileges ---- -
{{MDNSidebar}}

Voor sommige hulpmiddelen en handelingen op MDN zijn er verhoogde toegangsbevoegdheden nodig, die niet beschikbaar zijn voor normale gebruikers.

- -

Als u bevoegdheden wilt of nodig hebt voor een hulpmiddel, volg dan de onderstaande stappen:

- -
    -
  1. Open een Bugzilla-bug, waarin een beschrijving staat van wat u nodig heeft en waarom u het nodig heeft. Zet uw accountnaam op MDN erbij.
  2. -
  3. Zorg ervoor dat u uitleg waarom u voldoet aan de voorwaarden voor het verkrijgen van bevoegdheden, voor elk hulpmiddel waar u bevoegdheden voor aanvraagt. Bekijk hiervoor de 'Voorwaarden voor het verkrijgen van deze bevoegdheid' voor het hulpmiddel of de hulpmiddelen in kwestie.
  4. -
  5. U hebt twee gelijken nodig voor de betreffende tool, die voor u instaan in de bug.
  6. -
  7. Als aan 1-3 zijn voldaan, kan een van de MDN-admins u toegang geven tot het hulpmiddel dat of de hulpmiddelen die u nodig hebt.
  8. -
- -

Bij misbruik of een aanzienlijk probleem (zoals een recent ontdekte, gevaarlijke bug in het hulpmiddel) kan elke admin op elk moment de toegang tot een tool opschorten.

diff --git a/files/nl/mdn/guidelines/style_guide/index.html b/files/nl/mdn/guidelines/style_guide/index.html deleted file mode 100644 index 92fa1e530b..0000000000 --- a/files/nl/mdn/guidelines/style_guide/index.html +++ /dev/null @@ -1,502 +0,0 @@ ---- -title: MDN style guide -slug: MDN/Guidelines/Style_guide -translation_of: MDN/Guidelines/Writing_style_guide ---- -
{{MDNSidebar}}
- -

In an effort to display documentation in an organized, standardized and easy-to-read manner, the Mozilla Developer Network style guide describes how text should be organized, spelled, formatted, and so on. These are guidelines rather than strict rules. We are more interested in content than formatting, so don't feel obligated to learn the style guide before contributing. Do not be upset or surprised, however, if an industrious volunteer later edits your work to conform to this guide.

- -

If you're looking for specifics of how a given type of page should be structured, see the MDN page layout guide.

- -

The language aspects of this guide apply primarily to English-language documentation. Other languages may have (and are welcome to create) their own style guides. These should be published as subpages of the localization team's page.

- -

For style standards that apply to content written for sites other than MDN, refer to the One Mozilla style guide.

- -

Basics

- -

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 like this:

- - - -

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.

- -

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".

- -

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.

- - - -

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. -
  3. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
  4. -
  5. An optional "Browser compatibility" section at the bottom of the page.
  6. -
- - - -

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-hand 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-hand column should contain one or more of the following sections, in order:

- -
-
Getting help from the community
-
This should provide information on Matrix 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. -
  3. Create an image in the WYSIWYG editor
  4. -
  5. In the WYSIWYG editor in the drop-down list listing attachments, select the newly created attachment which is your image
  6. -
  7. Press OK.
  8. -
- -

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/nl/mdn/guidelines/writing_style_guide/index.html b/files/nl/mdn/guidelines/writing_style_guide/index.html new file mode 100644 index 0000000000..92fa1e530b --- /dev/null +++ b/files/nl/mdn/guidelines/writing_style_guide/index.html @@ -0,0 +1,502 @@ +--- +title: MDN style guide +slug: MDN/Guidelines/Style_guide +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +

In an effort to display documentation in an organized, standardized and easy-to-read manner, the Mozilla Developer Network style guide describes how text should be organized, spelled, formatted, and so on. These are guidelines rather than strict rules. We are more interested in content than formatting, so don't feel obligated to learn the style guide before contributing. Do not be upset or surprised, however, if an industrious volunteer later edits your work to conform to this guide.

+ +

If you're looking for specifics of how a given type of page should be structured, see the MDN page layout guide.

+ +

The language aspects of this guide apply primarily to English-language documentation. Other languages may have (and are welcome to create) their own style guides. These should be published as subpages of the localization team's page.

+ +

For style standards that apply to content written for sites other than MDN, refer to the One Mozilla style guide.

+ +

Basics

+ +

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 like this:

+ + + +

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.

+ +

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".

+ +

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.

+ + + +

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. +
  3. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
  4. +
  5. An optional "Browser compatibility" section at the bottom of the page.
  6. +
+ + + +

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-hand 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-hand column should contain one or more of the following sections, in order:

+ +
+
Getting help from the community
+
This should provide information on Matrix 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. +
  3. Create an image in the WYSIWYG editor
  4. +
  5. In the WYSIWYG editor in the drop-down list listing attachments, select the newly created attachment which is your image
  6. +
  7. Press OK.
  8. +
+ +

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/nl/mdn/kuma/index.html b/files/nl/mdn/kuma/index.html deleted file mode 100644 index 8c20ce6be7..0000000000 --- a/files/nl/mdn/kuma/index.html +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 'Kuma: MDN’s wiki-platform' -slug: MDN/Kuma -tags: - - Kuma - - Landing - - MDN - - MDN Meta -translation_of: MDN/Kuma ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/nl/docs/MDN")}}
- -

Kuma is de Django-code die MDN Web Docs mogelijk maakt.

- -

{{SubpagesWithSummaries}}

- -

Meewerken aan Kuma

- -

Doe het volgende om aan Kuma mee te werken:

- - diff --git a/files/nl/mdn/kuma/probleemoplossingen_kumascript_errors/index.html b/files/nl/mdn/kuma/probleemoplossingen_kumascript_errors/index.html deleted file mode 100644 index 1c6e356ac9..0000000000 --- a/files/nl/mdn/kuma/probleemoplossingen_kumascript_errors/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Probleemoplossing KumaScript-errors -slug: MDN/Kuma/Probleemoplossingen_KumaScript_errors -tags: - - Documentatie(2) - - Errors - - Fouten - - KumaScript - - MDN -translation_of: MDN/Tools/KumaScript/Troubleshooting ---- -
{{MDNSidebar}}
-

KumaScript fouten die op pagina's verschijnen kunnen ontmoedigend zijn voor degene die deze tegenkomen. Gelukkig kan iedereen met een MDN-account deze documenten bewerken om deze bugs op te lossen. Wanneer een pagina deze fout toont, wordt deze toegevoegd aan de lijst documenten met fouten.  Site editors spitten deze regelmatig door om deze bugs te vinden en ze op te lossen. Dit artikel omschrijft vier typen KumaScript-fouten, en hoe je deze kunt oplossen.

-
- -

DocumentParsingError

- -

DocumentParsingError verschijnt wanneer KumaScript problemen heeft met het begrijpen van het document zelf. De meest voorkomende oorzaak is een syntax error(een character of string verkeerd geplaatst in een command of instruction waardoor een storing ontstaat in het uitvoeren) in een macro.

- -

Controleren op:

- -
-
Het gebruik van accolades zonder de bedoeling een macro op te roepen.
-
Als u een \{ wilt schrijven in een document zonder een macro aan te roepen, kunt u dit doen door een extra \ ervoor toe te voegen. Zoals dit: \\{
-
Het gebruik van een speciaal karakter in een macro parameter.
-
Wanneer u een \ of een "  binnenin een macro parameter nodig heeft, kunt u dit doen door een \ ervoor toe te voegen. Zoals dit: \\ of \"
-
Ontbrekende komma tussen macro parameters.
-
Macro parameters moeten afgebakend worden door een komma (,) maar niet aan het einde van de lijst van parameters, voorbeeld; \{\{anch("top", "Back to top")}}.
-
HTML tags verschijnen in een macro oproep
-
Als je styling/vormgeving toepast in een macro, zal het vaak breken omdat, bijvoorbeeld een </code> tag verschenen is in de geschreven macro code van de broncode. Controleer de bron om te zien wat er is en verwijder onnodige styling/vormgeving.
-
- - - -

TemplateLoadingError

- -

TemplateLoadingError verschijnt wanneer Kumascript moeite heeft met het bepalen welke macro op de pagina te include

- -

Controleer op:

- -
-
Verkeerd gespelde macro namen of hernoemde macro's.
-
U kunt proberen te kijken of de macro juist genoemd is in de sjabloonpagina. De URL van de sjabloonpagina kan worden berekend door de naam template aan het einde van de URL toe te voegen; https://developer.mozilla.org/en-US/docs/Template: — bijvoorbeeld de sjabloonpagina voor \{\{anch("top", "Back to top")}}  is https://developer.mozilla.org/en-US/docs/Template:anch.
-
- Er is een gedeeltelijke lijst van macros voor de MDN, die de bestaande macro's en zijn correcte/nieuwe spelling kan omvatten.
-
- -
-

Tip: Je kan een snelle en makkelijke sprong maken naar een specifieke macro door een zoekwoord toe te voegen aan Firefox. <<<Meer info binnenkort>>>

-
- -

TemplateExecutionError

- -

TemplateExecutionError verschijnt wanneer KumaScript een fout treft in de macro. Deze fouten kunnen alleen worden opgelost door admins/beheerders en moeten gerapporteerd worden als bugs.

- -

Controleer voordat je fouten rapporteerd, of deze fout al opgelost is. Dit kun je doen door Shift ingedrukt te houden terwijl je de KumaScript pagina herlaadt (Shift + Ctrl + R op Windows/Linux, Shift + Cmd + R op Mac).

- -

Meldt een bug wanneer de fout niet opgelost wordt, voeg hierbij de URL van de pagina en de de tekst in de foutmelding.

- -

Overige fouten

- -

Dit is de categorie waar niet bovenstaande fouten tot behoren.

- -

Controleer voor fixes en rapporteer hardnekkige bugs zoals beschreven onder TemplateExecutionError.

- -

 

- -

 

diff --git a/files/nl/mdn/over/index.html b/files/nl/mdn/over/index.html deleted file mode 100644 index 9af7825aab..0000000000 --- a/files/nl/mdn/over/index.html +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Over MDN -slug: MDN/Over -tags: - - Auteursrechten - - Collaboratie - - Community - - Documentație - - Gids - - Licenties - - MDN Meta -translation_of: MDN/About ---- -
{{MDNSidebar}}
- -
{{IncludeSubNav("/nl/docs/MDN")}}
- -

MDN Web Docs is een evoluerend leerplatform voor webtechnologieën en de software die het Web van zijn kracht voorziet, zoals:

- - - -

Onze missie

- -

MDN's missie is simpelweg ontwikkelaars de informatie bieden die ze nodig hebben om eenvoudig projecten op het open Web te creëren. Als het een open technologie is die wordt blootgesteld aan het web, willen we het documenteren.

- -

Daarnaast bieden we documentatie over Mozillaproducten en hoe te bouwen en bij te dragen aan Mozillaprojecten.

- -

Als u onzeker bent of een specifiek onderwerp wel of niet past  op MDN, lees dan: Hoort dit op MDN?

- -

Hoe u kunt helpen

- -

U hoeft niet te kunnen coderen—of goed kunnen schrijven—om MDN te kunnen helpen! We hebben vele manieren waarop men kan helpen, van het beoordelen van artikelen om er zeker van te zijn dat ze logisch zijn, tot het bijdragen van tekst en het toevoegen van voorbeeldcode. In feite zijn er zoveel manieren om te helpen dat we een pagina, genaamd Beginnen op MDN, hebben die u helpt een taak te kiezen, gebaseerd op uw interesses en hoeveel tijd u hebt!

- -

U kunt ook helpen door het promoten van MDN op uw eigen blog of website.

- -

De MDN-gemeenschap

- -

Onze gemeenschap is een wereldwijde! We hebben geweldige bijdragers over de hele wereld, in verschillende talen. Als u meer wilt weten over ons, of als u hulp nodig hebt met MDN op welke manier dan ook, neem dan gerust een kijkje op ons discussieforum of IRC-kanaal! U kunt ook bijhouden wat we doen door ons Twitter-account te volgen, @MozDevNet. U kunt ook tweets naar ons verzenden als u ziet dat er iets verkeerd is, of als u feedback wilt geven (of bedankjes) aan onze schrijvers en bijdragers!

- -

De inhoud van MDN Web Docs gebruiken

- -

Auteursrechten en licenties

- -

MDN's wikidocumenten zijn opgesteld met de bijdragen van vele auteurs, zowel binnen als buiten de Mozilla Foundation. Tenzij anders aangegeven, is de inhoud beschikbaar onder de voorwaarden van de Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 of een latere versie. Schrijf "Mozilla-bijdragers" toe en voeg een hyperlink (online) of URL (in gedrukte vorm) toe aan de specifieke wikipagina voor de inhoud die wordt aangekocht. Als u bijvoorbeeld een toeschrijving voor dit artikel wilt geven, kunt u schrijven:

- -
Over MDN door Mozilla Bijdragers is onder licentie van CC-BY-SA 2.5.
- -

"Mozilla Bijdragers" verwijst naar de geschiedenis van de geciteerde pagina. Zie Best practices for attribution voor verdere uitleg.

- -
-

Zie MDN content op WebPlatform.org voor informatie over hoe u MDN-inhoud op die site kunt hergebruiken en toeschrijven.

-
- -

Codevoorbeelden die zijn toegevoegd voor 20 augustus 2010, zijn beschikbaar onder de MIT-licentie; U moet de volgende attributie-informatie in het MIT-sjabloon zetten: "© <datum van laatste herziening van de wikipagina> <naam van de persoon die het in de wiki heeft geplaatst>".

- -

Codevoorbeelden toegevoegd op of na 20 augustus 2010 zijn in het publiek domein. Er is geen licentie nodig, maar als er een nodig is, kunt u de volgende gebruiken: "Alle auteursrechten zijn opgedragen aan het publiek domein. http://creativecommons.org/publicdomain/zero/1.0/".

- -

Als u een bijdrage wilt leveren aan deze wiki, moet u uw documentatie beschikbaar maken onder de Attribution-ShareAlike-licentie (of soms een alternatieve licentie die al is opgegeven door de pagina die u aan het bewerken bent) en uw codevoorbeelden beschikbaar maken onder Creative Commons CC-0 (een publiek-domeinaanduiding). Door bij te dragen aan deze wiki, stemt u ermee in dat uw bijdragen onder die licenties beschikbaar worden gesteld.

- -

Sommige oudere inhoud was beschikbaar gemaakt onder een andere licentie dan hierboven genoteerd; deze staan onderaan elke pagina genoteerd aan de hand van een Alternatief licentieblok.

- -
-

Er mogen geen nieuwe pagina's gemaakt worden met andere licenties.

-
- -

Auteursrecht voor ingebrachte materialen blijft bij de auteur, tenzij de auteur het aan iemand anders toewijst.

- -

Als u vragen of opmerkingen hebt over alles wat hier wordt besproken, neem dan contact op met Eric Shepherd.

- -
-

De rechten op de handelsmerken, logo's, servicemerken van de Mozilla Foundation en het uiterlijk van deze website zijn niet gelicentieerd onder de Creative Commons-licentie en voor zover het werken van auteurschap betreft (zoals logo's en grafische afbeeldingen) ontwerp), zijn ze niet opgenomen in het werk dat onder die voorwaarden is gelicentieerd. Als u de tekst van documenten gebruikt en tevens een van deze rechten wilt gebruiken, of als u andere vragen hebt over het voldoen aan onze licentievoorwaarden voor deze verzameling, dient u hier contact op te nemen met de Mozilla Foundation: licensing@mozilla.org.

- - - -

Linken naar MDN

- -

Zie dit artikel voor begeleiding op linken naar MDN voor de beste uitvoeringen bij het linken.

- - - - - -

Downloaden van content

- -

U kunt een volledige tarball mirror van MDN downloaden (2.1 GB vanaf februari 2017).

- -

Enkele pagina's

- -

U kunt de inhoud van één pagina op MDN ophalen door documentparameters toe te voegen aan de URL om op te geven welke indeling u wilt.

- -

Third-party tools

- -

U kunt MDN content bekijken via third-party tools zoals Dash (voor Mac OS) en Zeal (voor Linux en Windows).

- -

Kapeli publiceert ook offline MDN docs over HTML, CSS, JavaScript, SVG, en XSLT.

- -

Problemen rapporteren met MDN Web Docs

- -

Zie Hoe rapporteert men een probleem op MDN.

- -

Geschiedenis van MDN Web Docs

- -

Het MDN Web Docs (voorheen Mozilla Developer Network (MDN), voorheen Mozilla Developer Center (MDC), a.k.a. Devmo) project startte begin 2005, toen de Mozilla Foundation Een licentie van AOL verkreeg om de originele Netscape DevEdge content te gebruiken. De DevEdge-inhoud werd gedolven voor nog bruikbaar materiaal, dat vervolgens door vrijwilligers werd gemigreerd naar deze wiki, zodat het gemakkelijker te updaten en onderhouden was.

- -

U kunt meer geschiedenis van MDN vinden op onze 10-jarig jubileum-pagina, inclusief een mondelinge geschiedenis door enkele van de mensen die erbij betrokken waren.

- -

Over Mozilla

- -

Of u nu meer wilt weten over wie we zijn, hoe u een deel van Mozilla kunt zijn of waar u ons kunt vinden, u bent hier aan het juiste adres. Als u wilt weten wat ons drijft en ons anders maakt, bezoek dan onze missiepagina.

diff --git a/files/nl/mdn/tools/kumascript/troubleshooting/index.html b/files/nl/mdn/tools/kumascript/troubleshooting/index.html new file mode 100644 index 0000000000..1c6e356ac9 --- /dev/null +++ b/files/nl/mdn/tools/kumascript/troubleshooting/index.html @@ -0,0 +1,69 @@ +--- +title: Probleemoplossing KumaScript-errors +slug: MDN/Kuma/Probleemoplossingen_KumaScript_errors +tags: + - Documentatie(2) + - Errors + - Fouten + - KumaScript + - MDN +translation_of: MDN/Tools/KumaScript/Troubleshooting +--- +
{{MDNSidebar}}
+

KumaScript fouten die op pagina's verschijnen kunnen ontmoedigend zijn voor degene die deze tegenkomen. Gelukkig kan iedereen met een MDN-account deze documenten bewerken om deze bugs op te lossen. Wanneer een pagina deze fout toont, wordt deze toegevoegd aan de lijst documenten met fouten.  Site editors spitten deze regelmatig door om deze bugs te vinden en ze op te lossen. Dit artikel omschrijft vier typen KumaScript-fouten, en hoe je deze kunt oplossen.

+
+ +

DocumentParsingError

+ +

DocumentParsingError verschijnt wanneer KumaScript problemen heeft met het begrijpen van het document zelf. De meest voorkomende oorzaak is een syntax error(een character of string verkeerd geplaatst in een command of instruction waardoor een storing ontstaat in het uitvoeren) in een macro.

+ +

Controleren op:

+ +
+
Het gebruik van accolades zonder de bedoeling een macro op te roepen.
+
Als u een \{ wilt schrijven in een document zonder een macro aan te roepen, kunt u dit doen door een extra \ ervoor toe te voegen. Zoals dit: \\{
+
Het gebruik van een speciaal karakter in een macro parameter.
+
Wanneer u een \ of een "  binnenin een macro parameter nodig heeft, kunt u dit doen door een \ ervoor toe te voegen. Zoals dit: \\ of \"
+
Ontbrekende komma tussen macro parameters.
+
Macro parameters moeten afgebakend worden door een komma (,) maar niet aan het einde van de lijst van parameters, voorbeeld; \{\{anch("top", "Back to top")}}.
+
HTML tags verschijnen in een macro oproep
+
Als je styling/vormgeving toepast in een macro, zal het vaak breken omdat, bijvoorbeeld een </code> tag verschenen is in de geschreven macro code van de broncode. Controleer de bron om te zien wat er is en verwijder onnodige styling/vormgeving.
+
+ + + +

TemplateLoadingError

+ +

TemplateLoadingError verschijnt wanneer Kumascript moeite heeft met het bepalen welke macro op de pagina te include

+ +

Controleer op:

+ +
+
Verkeerd gespelde macro namen of hernoemde macro's.
+
U kunt proberen te kijken of de macro juist genoemd is in de sjabloonpagina. De URL van de sjabloonpagina kan worden berekend door de naam template aan het einde van de URL toe te voegen; https://developer.mozilla.org/en-US/docs/Template: — bijvoorbeeld de sjabloonpagina voor \{\{anch("top", "Back to top")}}  is https://developer.mozilla.org/en-US/docs/Template:anch.
+
+ Er is een gedeeltelijke lijst van macros voor de MDN, die de bestaande macro's en zijn correcte/nieuwe spelling kan omvatten.
+
+ +
+

Tip: Je kan een snelle en makkelijke sprong maken naar een specifieke macro door een zoekwoord toe te voegen aan Firefox. <<<Meer info binnenkort>>>

+
+ +

TemplateExecutionError

+ +

TemplateExecutionError verschijnt wanneer KumaScript een fout treft in de macro. Deze fouten kunnen alleen worden opgelost door admins/beheerders en moeten gerapporteerd worden als bugs.

+ +

Controleer voordat je fouten rapporteerd, of deze fout al opgelost is. Dit kun je doen door Shift ingedrukt te houden terwijl je de KumaScript pagina herlaadt (Shift + Ctrl + R op Windows/Linux, Shift + Cmd + R op Mac).

+ +

Meldt een bug wanneer de fout niet opgelost wordt, voeg hierbij de URL van de pagina en de de tekst in de foutmelding.

+ +

Overige fouten

+ +

Dit is de categorie waar niet bovenstaande fouten tot behoren.

+ +

Controleer voor fixes en rapporteer hardnekkige bugs zoals beschreven onder TemplateExecutionError.

+ +

 

+ +

 

diff --git a/files/nl/mdn/tools/template_editing/index.html b/files/nl/mdn/tools/template_editing/index.html deleted file mode 100644 index 51ce66b56b..0000000000 --- a/files/nl/mdn/tools/template_editing/index.html +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Sjablonen bewerken -slug: MDN/Tools/Template_editing -tags: - - Gids - - Hulpmiddelen - - MDN - - MDN Meta - - Paginaniveau - - Privileges - - Rollen(2) -translation_of: MDN/Tools/Template_editing ---- -
{{MDNSidebar}}

Op MDN worden in KumaScript geschreven sjablonen gebruikt om het genereren en aanpassen van inhoud binnen pagina's te automatiseren. Elk sjabloon is een apart bestand in de map macros op de GitHub-repository van KumaScript.

- -

Iedereen die wikipagina's op MDN bewerkt, kan macro's aanroepen in MDN-artikelen. Daarnaast kan iedereen sjablonen aanmaken en bewerken via de GitHub-repository van KumaScript, waarbij standaard open-source-gewoonten worden gebruikt (fork de repo, maak een branch, maak wijzigingen en stuur een pull-request ter beoordeling). Op dit moment is het sturen van een pull-request de enige manier om vertaalde strings bij te werken in sjablonen die deze strings bevatten.

diff --git a/files/nl/mdn/yari/index.html b/files/nl/mdn/yari/index.html new file mode 100644 index 0000000000..8c20ce6be7 --- /dev/null +++ b/files/nl/mdn/yari/index.html @@ -0,0 +1,27 @@ +--- +title: 'Kuma: MDN’s wiki-platform' +slug: MDN/Kuma +tags: + - Kuma + - Landing + - MDN + - MDN Meta +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/nl/docs/MDN")}}
+ +

Kuma is de Django-code die MDN Web Docs mogelijk maakt.

+ +

{{SubpagesWithSummaries}}

+ +

Meewerken aan Kuma

+ +

Doe het volgende om aan Kuma mee te werken:

+ + -- cgit v1.2.3-54-g00ecf