From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/fr/mdn/a_propos/index.html | 30 ++ files/fr/mdn/contribute/feedback/index.html | 52 +++ files/fr/mdn/contribute/getting_started/index.html | 110 +++++ .../index.html" | 45 ++ .../convertir_code_pour_etre_direct/index.html | 30 ++ .../index.html | 190 ++++++++ .../faire_relecture_redactionnelle/index.html | 55 +++ .../howto/faire_relecture_technique/index.html | 42 ++ files/fr/mdn/contribute/howto/index.html | 13 + .../howto/lier_un_compte_github/index.html | 17 + .../howto/set_the_summary_for_a_page/index.html | 60 +++ .../write_a_new_entry_in_the_glossary/index.html | 117 +++++ .../index.html | 129 ++++++ .../\303\251tiquettes_pages_javascript/index.html" | 74 +++ files/fr/mdn/contribute/index.html | 69 +++ files/fr/mdn/contribute/localize/index.html | 29 ++ .../localize/translating_pages/index.html | 51 +++ files/fr/mdn/contribute/persona_sign-in/index.html | 32 ++ files/fr/mdn/contribute/processes/index.html | 17 + files/fr/mdn/editor/basics/index.html | 74 +++ .../fr/mdn/editor/basics/pieces_jointes/index.html | 74 +++ files/fr/mdn/editor/index.html | 226 +++++++++ .../guidelines/code_lignesdirectrices/index.html | 77 ++++ files/fr/mdn/guidelines/index.html | 13 + files/fr/mdn/index.html | 37 ++ files/fr/mdn/kuma/index.html | 24 + .../conversations/index.html" | 56 +++ .../doc_sprints/index.html" | 133 ++++++ .../mdn/rejoindre_la_communaut\303\251/index.html" | 51 +++ .../roles/admins/index.html" | 57 +++ .../roles/index.html" | 13 + .../role_de_pilote_de_localisation/index.html" | 71 +++ .../roles/role_du_conducteur_de_sujet/index.html" | 82 ++++ .../roles/role_du_mentor/index.html" | 64 +++ .../whats_happening/index.html" | 42 ++ files/fr/mdn/structures/exemples_live/index.html | 250 ++++++++++ files/fr/mdn/structures/index.html | 17 + .../macros/commonly-used_macros/index.html | 224 +++++++++ files/fr/mdn/structures/macros/index.html | 40 ++ .../tables_de_compatibilit\303\251/index.html" | 503 +++++++++++++++++++++ files/fr/mdn/tools/index.html | 16 + files/fr/mdn/tools/kumascript/index.html | 499 ++++++++++++++++++++ files/fr/mdn/tools/template_editing/index.html | 15 + files/fr/mdn/user_guide/index.html | 13 + .../fr/mdn/user_guide/r\303\251daction/index.html" | 61 +++ 45 files changed, 3894 insertions(+) create mode 100644 files/fr/mdn/a_propos/index.html create mode 100644 files/fr/mdn/contribute/feedback/index.html create mode 100644 files/fr/mdn/contribute/getting_started/index.html create mode 100644 "files/fr/mdn/contribute/howto/comment_cr\303\251er_un_compte_sur_mdn/index.html" create mode 100644 files/fr/mdn/contribute/howto/convertir_code_pour_etre_direct/index.html create mode 100644 files/fr/mdn/contribute/howto/creer_un_exercice_interactif_pour_apprendre_le_web/index.html create mode 100644 files/fr/mdn/contribute/howto/faire_relecture_redactionnelle/index.html create mode 100644 files/fr/mdn/contribute/howto/faire_relecture_technique/index.html create mode 100644 files/fr/mdn/contribute/howto/index.html create mode 100644 files/fr/mdn/contribute/howto/lier_un_compte_github/index.html create mode 100644 files/fr/mdn/contribute/howto/set_the_summary_for_a_page/index.html create mode 100644 files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html create mode 100644 files/fr/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html create mode 100644 "files/fr/mdn/contribute/howto/\303\251tiquettes_pages_javascript/index.html" create mode 100644 files/fr/mdn/contribute/index.html create mode 100644 files/fr/mdn/contribute/localize/index.html create mode 100644 files/fr/mdn/contribute/localize/translating_pages/index.html create mode 100644 files/fr/mdn/contribute/persona_sign-in/index.html create mode 100644 files/fr/mdn/contribute/processes/index.html create mode 100644 files/fr/mdn/editor/basics/index.html create mode 100644 files/fr/mdn/editor/basics/pieces_jointes/index.html create mode 100644 files/fr/mdn/editor/index.html create mode 100644 files/fr/mdn/guidelines/code_lignesdirectrices/index.html create mode 100644 files/fr/mdn/guidelines/index.html create mode 100644 files/fr/mdn/index.html create mode 100644 files/fr/mdn/kuma/index.html create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/conversations/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/doc_sprints/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/roles/admins/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/roles/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_de_pilote_de_localisation/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_conducteur_de_sujet/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_mentor/index.html" create mode 100644 "files/fr/mdn/rejoindre_la_communaut\303\251/whats_happening/index.html" create mode 100644 files/fr/mdn/structures/exemples_live/index.html create mode 100644 files/fr/mdn/structures/index.html create mode 100644 files/fr/mdn/structures/macros/commonly-used_macros/index.html create mode 100644 files/fr/mdn/structures/macros/index.html create mode 100644 "files/fr/mdn/structures/tables_de_compatibilit\303\251/index.html" create mode 100644 files/fr/mdn/tools/index.html create mode 100644 files/fr/mdn/tools/kumascript/index.html create mode 100644 files/fr/mdn/tools/template_editing/index.html create mode 100644 files/fr/mdn/user_guide/index.html create mode 100644 "files/fr/mdn/user_guide/r\303\251daction/index.html" (limited to 'files/fr/mdn') diff --git a/files/fr/mdn/a_propos/index.html b/files/fr/mdn/a_propos/index.html new file mode 100644 index 0000000000..be8fecffe1 --- /dev/null +++ b/files/fr/mdn/a_propos/index.html @@ -0,0 +1,30 @@ +--- +title: À propos +slug: MDN/A_propos +tags: + - MDN +translation_of: MDN/About +--- +
{{MDNSidebar}}

Le Mozilla Developer Network (MDN) est une plateforme évoluée d’apprentissage des technologies web et des logiciels qui animent le Web, notamment :

+ + + +

Comment aider

+ +

Il n’est pas nécessaire de savoir coder — ou même écrire — pour contribuer à MDN ! Il existe de nombreuses façons d’aider, de la relecture d’articles à l’ajout d’exemples de code. À vrai dire, il y a tellement de moyens de participer que nous avons même un outil permettant d’aider à choisir une tâche en se basant sur ce qui vous intéresse et combien de temps vous avez à donner !

+ +

Historique du projet

+ +

Le projet Mozilla Developer Network (à l’origine Mozilla Developer Center (MDC) ou encore Devmo) a commencé début 2005, lorsque la fondation Mozilla a obtenu une licence d'AOL afin d'utiliser le contenu original de l'ancien site de documentation de Netscape, DevEdge. Le contenu existant a été trié pour en retirer les parties qui étaient encore utiles. Migrées par des bénévoles vers ce wiki, les pages seront plus faciles à mettre à jour et à enrichir.

+ +

Depuis, le projet a continué à grandir formant à présent un point central pour toutes les documentations destinées aux développeur·se·s lié·e·s au projet Mozilla et aux technologies du Web ouvert. En 2010, le site s’est vu rebaptiser en Mozilla Developper Network. En 2011 furent lancés DemoStudio, permettant aux développeurs web de partager et exposer leur code, ainsi que les pages « Apprendre », proposant des liens vers des tutoriels. L’acronyme MDC subsiste encore aujourd’hui, et signifie « MDN Doc Center ». Dans l'avenir, le Mozilla Developer Network espère devenir une ressource visitée quotidiennement par les créateurs web, les développeurs d'applications, d'extensions et de thèmes.

+ +

Le système de wiki utilisé étant prévu pour être multilingue, différentes équipes de traduction se sont rapidement formées. La documentation existante en français pour les développeurs web est souvent très pauvre, ancienne et éparpillée. Des habitué·e·s de xulfr.org et de Geckozone se sont donc attelé·e·s à la tâche de traduire cette documentation pour un large public francophone. Mais nous sommes peu nombreux·ses et il y a énormément à faire, n'hésitez donc pas à nous rejoindre.

+ +

À propos de Mozilla

+ +

Que vous vouliez en apprendre plus sur nous, comment rejoindre Mozilla ou simplement où nous trouver, vous êtes au bon endroit. Pour comprendre ce qui nous motive et nous rend différents, rendez-vous sur notre page Mission.

diff --git a/files/fr/mdn/contribute/feedback/index.html b/files/fr/mdn/contribute/feedback/index.html new file mode 100644 index 0000000000..76afb125a8 --- /dev/null +++ b/files/fr/mdn/contribute/feedback/index.html @@ -0,0 +1,52 @@ +--- +title: Faire un retour sur MDN +slug: MDN/Contribute/Feedback +tags: + - Guide + - MDN + - MDN Meta +translation_of: MDN/Contribute/Feedback +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Bienvenue sur MDN.  Si vous avez des suggestions ou avez des problèmes avec MDN, vous êtes au bon endroit. Nous vous remercions par avance de l'intérêt que vous nous portez.

+ +

Il y existe plusieurs façons de nous aider, cet article va vous guider.

+ +

Mettre à jour la documentation

+ +

Premièrement, si vous avez remarqué un problème avec la documentation, vous devez vous sentir libre de la corriger par vous-même. Il suffit de s'inscrire en utilisant un compte GitHub puis de cliquer sur le bouton bleu « Modifier » afin d'ouvrir l'éditeur.

+ +

La documentation MDN est un wiki alimenté par une équipe de volontaires et du personnel rémunéré. Ne soyez pas timide, votre orthographe n'a pas a être parfaite, nous nettoyons les erreurs que nous voyons.

+ +

Pour plus d'information sur comment contribuer à la documentation :

+ + + +

Rejoignez la conversation

+ +

Parlez-nous ! Il y a plusieurs méthodes pour rentrer en contact avec les personnes qui travaillent sur le contenu de MDN.

+ +

Chat

+ +

+

Discussions (asynchrones)

+ + +

Les discussions plus importantes et qui ne nécessitent pas d'être connecté à tout moment se déroulent sur le forum Discourse. Vous pouvez envoyer des messages sur ce forum par e-mail en utilisant l'adresse mdn@mozilla-community.org. Si vous vous inscrivez sur le forum, vous pouvez également choisir de recevoir des notifications par e-mail à propos des discussions.

+ +

Rapporter un problème

+ +

Problème dans la documentation

+ +

Si vous voyez un problème avec la documentation et que vous ne pouvez pas la corriger vous-même pour une quelconque raison, vous pouvez rapporter un problème. Vous pouvez utiliser ce formulaire pour tout problème avec la documentation, qu'il s'agisse d'une simple correction ou d'un contenu complet. Comme expliqué précédemment, nous vous invitons à contribuer, mais cette option est facultative.

+ +

Problème sur le site

+ +

Si vous rencontrez un problème avec le site ou avez de nouvelles idées pour le site, vous pouvez envoyer un ticket à l'équipe de développement de MDN.

diff --git a/files/fr/mdn/contribute/getting_started/index.html b/files/fr/mdn/contribute/getting_started/index.html new file mode 100644 index 0000000000..6e5309b57e --- /dev/null +++ b/files/fr/mdn/contribute/getting_started/index.html @@ -0,0 +1,110 @@ +--- +title: Débuter sur MDN +slug: MDN/Contribute/Getting_started +tags: + - Débutant + - Guide + - Introduction + - MDN + - MDN Meta +translation_of: MDN/Contribute/Getting_started +--- +
{{MDNSidebar}}
{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Nous sommes une communauté ouverte de développeurs et rédacteurs et nous créons des ressources afin de rendre le Web meilleur, quels que soient la marque du matériel, le nom du navigateur ou la plate-forme de développement. Chacun peut contribuer et toute contribution est la bienvenue. Ensemble nous pouvons continuer à innover sur le Web et aider tous ses utilisateurs. Ça commence ici, avec vous.

+ +

Chaque composant de MDN (les documents, les démonstrations, le site lui-même) est créé par une communauté ouverte : rejoignez-la !

+ +

3 étapes pour contribuer à MDN

+ +

MDN est un wiki : n'importe qui peut ajouter et éditer du contenu. Il n'est pas nécessaire d'être développeur ou de s'y connaître beaucoup en technologie, il y a tellement de choses à faire ! Des choses simples — comme la relecture ou la correction typographique —  ou des choses plus complexes — comme la rédaction de la documentation d'une API.

+ +

Contribuer est facile et sans risque. Si vous faites une erreur, il sera facile de la corriger. Si vous n'êtes pas certain de ce à quoi doivent ressembler les choses ou que votre grammaire n'est pas parfaite, ne vous inquiétez pas ! Il existe d'autres personnes ici dont la tâche est de garantir la qualité du contenu de MDN. Il y aura donc toujours quelqu'un pour s'assurer que votre travail est valide. Partagez juste vos connaissances et suivez vos points forts : faites confiance au reste de la communauté pour améliorer encore votre travail.

+ +

Étape 1 : créer un compte sur MDN

+ +

Pour commencer à contribuer sur MDN, il est nécessaire d'avoir un compte. Pour plus de détails à ce sujet : comment créer un compte. Notez que vous aurez besoin d'un compte GitHub avant de pouvoir créer un compte sur MDN, car nous utilisons actuellement GitHub pour l'authentification.

+ +

Si vous avez besoin de créer de nouvelles pages, consultez Créer une page pour savoir comment obtenir la permission d'exécuter cette opération. Pour des raisons de sécurité, les nouveaux comptes ne peuvent pas créer de nouvelles pages.

+ +

Étape 2 : choisir une tâche

+ +

Une fois connecté, vous pouvez lire les descriptions des tâches proposées ci-dessous et choisir celle que vous souhaitez réaliser. Choisissez celle qui vous attire le plus pour commencer à contribuer !

+ +

Étape 3 : effectuer cette tâche

+ +

Une fois que vous avez choisi un type de tâche, vous pouvez trouver une page, un exemple de code, etc. sur quoi travailler.

+ +

Ne vous inquiétez pas si cela n'est pas parfait ; d'autres contributeurs MDN sont ici pour aider à corriger les erreurs qui pourraient vous échapper. Si vous avez des questions, jetez un œil sur la page Rejoindre la communauté où vous trouverez les listes de diffusion et les salons de discussions où vous pourrez trouver des réponses.

+ +
+

Note : Si vous voulez faire des expériences avant de faire une modification « pour de vrai », vous pouvez éditer la page Bac à sable. Limitez s'il vous plaît vos expérimentations à cette page. Ne faites pas de changements inutiles sur les pages de contenu afin d'observer le résultat, ceci perturbe les lecteurs et augmente la charge de travail des autres contributeurs qui doivent corriger/nettoyer.

+
+ +

Une fois que c'est fait, choisissez-en une autre ou voyez ce que vous pouvez faire d'autre sur MDN.

+ +

Les différents types de tâches

+ +

Vous pouvez emprunter plusieurs chemins pour contribuer sur MDN. Cela dépend avant tout de vos compétences, de vos intérêts et de votre curiosité. Bien que certaines tâches semblent difficiles, il en existe beaucoup qui peuvent être effectuées en quelques minutes ! Dans la liste qui suit, vous trouverez les tâches, leur description ainsi que le temps moyen estimé pour les mener à bien.

+ +

Option 1 : j'aime lire, écrire…

+ +

Vous pouvez nous aider à relire ou éditer certains articles et également les étiqueter (« tagger ») pour qu'ils soient mieux triés.

+ + + +
Note : Si vous relisez ou écrivez de nouveaux articles, veuillez lire le guide de mise en forme (en anglais). Cela permettra de s'assurer que l'ensemble des articles est cohérent.
+ +

Option 2 : j'aime coder

+ +

Nous avons besoin davantage d'exemples de codes ! Vous pouvez également contribuer à la plate-forme du site : Kuma.

+ + + +

Option 3 : j'aime coder mais aussi écrire

+ +

Certaines tâches requièrent des compétences linguistiques et informatiques comme l'écriture de nouveaux articles, des relectures techniques ou de l'adaptation de documents.

+ + + +

Option 4 : je veux que MDN soit traduit

+ +

Chaque travail de localisation et de traduction sur MDN est fait par une communauté de volontaires extraordinaires. Cet article liste chaque projet de localisation, les contributeurs et d'autres détails.

+ + + +

Option 5 : j'ai trouvé une information incorrecte mais je ne sais pas comment la corriger

+ +

Vous pouvez rapporter des problèmes en remplissant une fiche de bogue. (5 minutes)

+ +

Les valeurs à utiliser sont :

+ +
Note: les fiches de bogue sont à remplir en anglais. Si jamais vous souhaitez indiquer votre correction en français, la meilleure façon est de vous connecter sur #mozfr sur IRC ou bien d'envoyer un courriel à moz-fr [à] mozfr.org.
+ +

Les autres choses à faire sur MDN

+ + diff --git "a/files/fr/mdn/contribute/howto/comment_cr\303\251er_un_compte_sur_mdn/index.html" "b/files/fr/mdn/contribute/howto/comment_cr\303\251er_un_compte_sur_mdn/index.html" new file mode 100644 index 0000000000..a19f772968 --- /dev/null +++ "b/files/fr/mdn/contribute/howto/comment_cr\303\251er_un_compte_sur_mdn/index.html" @@ -0,0 +1,45 @@ +--- +title: Comment créer un compte sur MDN +slug: MDN/Contribute/Howto/Comment_créer_un_compte_sur_MDN +tags: + - Documentation + - Débutant + - Guide + - MDN Meta +translation_of: MDN/Contribute/Howto/Create_an_MDN_account +--- +
{{MDNSidebar}}

Pour modifier un article ou du contenu sur MDN, il vous faut un profil sur MDN. Pour parcourir MDN, vous n'avez besoin d'aucun profil, rassurez-vous. Dans le guide qui suit, on voit comment créer un profil MDN.

+ +
+
Pourquoi dois-je utiliser mon adresse électronique sur MDN ?
+
+Votre adresse électronique est utilisée pour récupérer votre compte et peut être utilisée par les administrateurs MDN afin de vous contacter (à propos de votre compte ou de vos contributions sur le site).
+
+Vous pouvez également l'utiliser pour vous abonner à des pages dont vous souhaitez connaître les modifications (voir cet article pour plus de détails) ou pour recevoir d'autres messages : par exemple, si vous vous inscrivez à la version beta, vous pouvez recevoir des messages relatifs à des fonctionnalités en cours de test.
+
+Votre adresse électronique n'est jamais affichée sur MDN et est uniquement utilisée dans le respect de notre politique de confidentialité. + +
Si vous vous connectez à MDN via GitHub et une adresse noreply, vous ne recevrez aucun message de MDN (même si vous vous abonnez aux modifications d'une page).
+
+
+ +
    +
  1. En haut de chaque article MDN, vous trouverez un bouton Connexion. Si vous cliquez dessus, cela affichera la liste des services pour s'authentifier sur MDN.
    2. +
  2. +

    Sélectionnez un de ces services. Actuellement, seul GitHub est disponible. En sélectionnant GitHub, votre page de profil MDN, publique, aura un lien vers votre profil GitHub.

    +
    3. +
  3. +

    Suivez ensuite les étapes de GitHub pour connecter votre compte à MDN.

    +
    4. +
  4. Une fois les étapes d'authentification terminée, vous reviendrez sur MDN où on vous demandera un nom d'utilisateur et une adresse électronique. Votre nom d'utilisateur sera public et utilisé pour vous attribuer vos contributions. N'utilisez pas votre adresse électronique comme nom d'utilisateur.
    5. +
  5. Cliquez sur Créez votre profil MDN.
    6. +
  6. Si l'adresse électronique utilisée à l'étape 4 n'est pas la même que celle utilisée avec le service d'authentification, veuillez vérifier votre messagerie électronique et cliquer sur le lien de confirmation que nous vous avons envoyé.
    7. +
+ +

Et voilà ! Vous avez désormais un compte MDN et vous pouvez éditer les articles !

+ +

Vous pouvez cliquer sur votre nom en haut de chaque page MDN afin de voir votre profil public. Depuis cette page de profil, vous pouvez cliquer sur Modifier pour éditer les informations de votre profil.

+ +
+

Note : Les noms d'utilisateur ne peuvent plus contenir d'espaces ou d'arobases (@). Attention, votre nom d'utilisateur sera utilisé publiquement afin d'identifier vos contributions !

+
diff --git a/files/fr/mdn/contribute/howto/convertir_code_pour_etre_direct/index.html b/files/fr/mdn/contribute/howto/convertir_code_pour_etre_direct/index.html new file mode 100644 index 0000000000..5ba1d36be9 --- /dev/null +++ b/files/fr/mdn/contribute/howto/convertir_code_pour_etre_direct/index.html @@ -0,0 +1,30 @@ +--- +title: Comment convertir des exemples de code pour qu'ils soient "live" +slug: MDN/Contribute/Howto/convertir_code_pour_etre_direct +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +--- +
{{MDNSidebar}}

MDN dispose d'un système d'exemples "live", grâce auxquels le code présent sur une page est exécuté pour afficher les résultats de l'exécution de ce code. Cependant, beaucoup d'articles existants affichent du code sans utiliser ce système, et ont donc besoin d'être convertis.

+ +

Les exemples "live", vous permettent de voir à quoi ressemble le résultat d'un exemple, faire une documentation plus dynamique et instructive. Ce guide vous explique comment prendre des exemples existants et leur rajouter la fonctionnalité "live".

+ +
+
Pour quels articles faire cela ?
+
Les articles marqués NeedsLiveSample
+
Quelles compétences pour réaliser cette tâche ?
+
+
    +
  • Comprendre le HTML, CSS et/ou JavaScript, selon le code implémenté
    • +
  • Savoir utiliser les macros KumaScript dans les articles du MDN
    • +
+
+
Quelles étapes pour réaliser cette tâche ?
+
+
    +
  1. Choisissez un article dans la liste de ceux marqués NeedsLiveSample, pour lequel le code présenté porte sur des notions qui vous sembles familières.
    2. +
  2. Convertissez le code pour qu'il soit "live"
    3. +
  3. Supprimer le code ou l'image qui montrait les sorties et résultats du programme. Votre exemple "live" le remplace désormais.
    4. +
+
+
+ +

Pour plus d'information sur la création et l'édition d'exemples "live", voir Utiliser le système d'exemple "live" (en anglais).

diff --git a/files/fr/mdn/contribute/howto/creer_un_exercice_interactif_pour_apprendre_le_web/index.html b/files/fr/mdn/contribute/howto/creer_un_exercice_interactif_pour_apprendre_le_web/index.html new file mode 100644 index 0000000000..edf746735b --- /dev/null +++ b/files/fr/mdn/contribute/howto/creer_un_exercice_interactif_pour_apprendre_le_web/index.html @@ -0,0 +1,190 @@ +--- +title: Comment créer un exercice interactif +slug: MDN/Contribute/Howto/Creer_un_exercice_interactif_pour_apprendre_le_web +tags: + - Apprendre + - Comment faire + - Guide + - Intermédiaire + - MDN Meta + - Tutoriel +translation_of: MDN/Contribute/Howto/Create_an_interactive_exercise_to_help_learning_the_web +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Quand on étudie le Web, il est important de pouvoir s'appuyer sur des exemples pratiques. Ce genre de contenu est là pour aider à apprendre de manière proactive. Ce peut être sous forme d'exercices, d'exemples interactifs, d'une liste de choses à faire, d'évaluations, etc. En un mot, tout ce qui peut amener quelqu'un à participer activement à son apprentissage.

+ +

Il n'existe pas de méthode directe pour créer un tel contenu. Par exemple, on peut trouver plusieurs sites tiers qui permettent de créer du code modifiable (voir : Glitch, JSFiddle, CodePen, Dabblet, etc.) que vous pouvez mettre en lien dans les articles MDN.

+ +

Pour le moment, MDN ne possède pas d'outil facilement accessible pour créer des exemples interactifs. Néanmoins, si vous êtes un développeur, vous pouvez utiliser directement des fonctionnalités MDN pour créer du contenu interactif personnalisé. Continuez la lecture pour en savoir plus.

+ +

Les lives samples

+ +

MDN possède une fonctionnalité assez cool, les live samples (qu'on pourrait traduire par exemple interactif). C'est un programme qui interprète un échantillon de code HTML, CSS, et JavaScript directement dans une page MDN. Avant de vous en servir, vous devriez lire Using the live sample system, qui est la documentation complète sur son utilisation. Bien qu'il soit facile à prendre en main, vous en apprendrez tout au long de son utilisation.

+ +

L'avantage est qu'il est vraiment facile d'exploiter cette fonctionnalité pour intégrer toute sorte d'exemples dont on a besoin dans une page MDN.

+ +

Le code caché

+ +

La meilleur moyen de créer un échantillon de code qui vous permettra de créer un exemple interactif est de construire la page dans laquelle vous voulez insérer votre contenu. Ne vous embetez pas avec la complexité du code; créez seulement ce dont vous avez besoin. Une fois qu'il est prêt, basculer vers l'éditeur de code et insérer celui-ci dans la balise {{HTMLElement('div')}} avec la classe hidden. En faisant ça, votre code ne sera pas affiché, mais votre échantillon restera accessible et modififable.

+ +

Prenons un exemple simple:

+ +
+

Cliquer sur le carré suivant pour changer sa couleur de manière aléatoire ou entrez un code couleur héxadécimal.

+ + +{{EmbedLiveSample('hidden_code_example', 120, 120)}}
+ +

Si on regarde le code HTML de l'éditeur MDN on retrouvera, lorsqu'il aura été géneré, exactement le code HTML suivant :

+ +
<div class="moreinfo">
+<p>Cliquer sur le carré suivant pour changer sa couleur de manière aléatoire ou entrez un code couleur héxadécimal.</p>
+
+<div class="hidden">
+<h4 id="hidden_code_example">Exemple de code caché</h4>
+
+<h5 id="HTML">HTML</h5>
+
+<pre class="brush: html">
+&lt;div class="square"&gt;
+  #&lt;input class="color"&gt;
+&lt;/div&gt;</pre>
+
+<h5 id="CSS">CSS</h5>
+
+<pre class="brush: css">
+body {
+  padding: 10px;
+  margin : 0;
+}
+
+.square {
+  width  : 80px;
+  height : 80px;
+  padding: 10px;
+  background-color: black;
+  color: white;
+  text-align: center;
+}
+
+.color {
+  width: 60px;
+  text-transform: uppercase;
+}
+</pre>
+
+<h5 id="JS">JS</h5>
+
+<pre class="brush: js">
+function setColor(color) {
+  document.querySelector('.square').style.backgroundColor = '#' + color;
+  document.querySelector('.color').value = color;
+}
+
+function getRandomColor() {
+  var color = Math.floor(Math.random() * 16777215);
+  return color.toString(16);
+}
+
+function getInputColor() {
+  var value = document.querySelector('.color').value;
+  var color = Number('0x' + color);
+  if (color === +color) {
+    return color.toString(16);
+  }
+  return value;
+}
+
+document.addEventListener('click', function () {
+  setColor(getRandomColor());
+});
+
+document.addEventListener('keyup', function () {
+  setColor(getInputColor());
+});
+</pre>
+</div>
+
+\{{EmbedLiveSample('hidden_code_example', 120, 120)}}
+</div>
+ +

Vous trouverez des exemples plus avancés dans la page sur l'API Canvas API.

+ +

Code externe

+ +

L'exemple précédent est suffisant pour intégrer des exemples basiques. Néanmoins, si vous voulez traiter du code plus complexe, cela peut devenir assez difficile uniquement à l'aide de la classe hidden.

+ +

L'autre option est d'écrire votre code dans une page MDN et de l'insérer ensuite dans une autre. On peut utiliser le macro {{TemplateLink("EmbedDistLiveSample")}} au lieu de {{TemplateLink("EmbedLiveSample")}}.

+ +

Voici à quoi cet exemple ressemble lorsqu'il est intégré à l'aide de la méthode distante :

+ +
+

Cliquer sur le carré suivant pour changer sa couleur de manière aléatoire ou entrez un code couleur héxadécimal.

+{{EmbedLiveSample('The_example', 120, 120, '', 'MDN/Contribute/Howto/Create_an_interactive_exercise_to_help_learning_the_web/distant_example')}}
+ +

Cette fois, si vous allez sur cette page avec l'éditeur MDN, vous ne verrez pas de code caché. Si vous voulez voir le code, allez sur la page qui l'héberge.

+ +

Vous trouverez des exemples plus avancés sur le tutoriel sur les formulaires HTML, qui appliquent ces méthodes pour permettre leur utilisation sur des formulaires.

diff --git a/files/fr/mdn/contribute/howto/faire_relecture_redactionnelle/index.html b/files/fr/mdn/contribute/howto/faire_relecture_redactionnelle/index.html new file mode 100644 index 0000000000..4a6d2d8770 --- /dev/null +++ b/files/fr/mdn/contribute/howto/faire_relecture_redactionnelle/index.html @@ -0,0 +1,55 @@ +--- +title: Comment faire une relecture rédactionnelle +slug: MDN/Contribute/Howto/faire_relecture_redactionnelle +tags: + - Documentation + - Guide + - MDN Meta + - Revue éditoriale +translation_of: MDN/Contribute/Howto/Do_an_editorial_review +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Une revue éditoriale consiste à corriger des fautes d'orthographe, de grammaire ou d'usage dans le texte d'un article. Il n'est pas nécessaire d'être un expert linguistique pour contribuer et toute relecture et correction attentive représente une contribution extrêmement utile.

+ +

Dans cet article, on décrit ce qu'est une revue éditoriale et comment aider à ce que le contenu de MDN soit formulé précisément.

+ +
+
Qu'est-ce que cette tâche ?
+
Il s'agit de relire et de corriger les articles ayant été marqués comme nécessitant une revue éditoriale.
+
Où faut-il accomplir cette tâche ?
+
Les revues éditoriales concernent principalement les articles qui ont été marqués comme nécessitant une revue éditoriale.
+
Que faut-il savoir pour accomplir cette tâche ?
+
Il faut avoir de bonnes notions en grammaire et en orthographe. Une revue éditoriale consiste à vérifier la grammaire, l'orthographe et les formulations utilisées dans un article. C'est également l'occasion de vérifier que le guide stylistique de MDN est bien respecté.
+
Quelles sont les étapes à suivre ?
+
+
    +
  1. Choisissez un article à relire : +
      +
    1. Consultez la liste des articles en attente d'une revue éditoriale. Cette page liste l'ensemble des articles pour lesquels ont été demandées des revues éditoriales.
      2. +
    2. Cliquez sur le lien d'un article pour charger la page.
      + Note : cette liste est générée de façon automatique mais peut ne pas être rafraîchie. Si l'article que vous avez choisi ne contient plus la bannière Cet article doit recevoir les relectures suivantes, vous pouvez rafraîchir la page avec la liste et en choisir un autre.
      3. +
    +
    2. +
  2. Lisez l'article avec précaution en faisant attention aux coquilles, fautes d'orthographe ou de grammaire ou aux formulations approximatives. N'hésitez pas à changer d'article si celui que vous avez choisi ne vous convient pas.
    3. +
  3. S'il n'y a pas d'erreur, vous n'avez pas besoin de modifier l'article pour terminer la relecture. Vous pouvez utiliser la zone présente dans la barre verticale à gauche de l'article :
    + capture d’écran de la boite de menu latéral indiquant une demande de relecture rédactionnelle
    4. +
  4. Décocher la case marquée Rédactionnel puis cliquer sur Enregistrer.
    5. +
  5. Si vous décelez des erreurs : +
      +
    1. Cliquez sur le bouton Modifier en haut de la page, vous accéderez alors à l'éditeur.
      2. +
    2. Corrigez les fautes trouvées. Si vous n'avez pas le temps ou que vous ne pensez pas avoir corrigé toutes les fautes, ce n'est pas grave et cela représente déjà une contribution essentielle, auquel cas, vous pouvez laisser la demande de revue sur la page.
      3. +
    3. Saisissez un commentaire de révision dans la zone en bas de l'article (par exemple : Revue éditoriale effectuée, correction de XX). Cela permet aux autres contributeurs et aux éditeurs de savoir ce que vous avez modifié et pourquoi.
      4. +
    4. Décochez la case Rédactionnel dans la zone Relecture nécessaire ? Cette zone est située juste avant les commentaires de révision.
      5. +
    5. Enfin, cliquez sur le bouton Publier.
      6. +
    +
    6. +
+ +
+

Note : Vos modifications peuvent ne pas être immédiatement visibles après l'enregistrement en raison du traitement de la page par le système. Vous pouvez rafraîchir la page après quelques instants pour résoudre ce problème s'il se présente.

+
+
+
diff --git a/files/fr/mdn/contribute/howto/faire_relecture_technique/index.html b/files/fr/mdn/contribute/howto/faire_relecture_technique/index.html new file mode 100644 index 0000000000..d2e299a83c --- /dev/null +++ b/files/fr/mdn/contribute/howto/faire_relecture_technique/index.html @@ -0,0 +1,42 @@ +--- +title: Comment faire une relecture technique +slug: MDN/Contribute/Howto/faire_relecture_technique +translation_of: MDN/Contribute/Howto/Do_a_technical_review +--- +
{{MDNSidebar}}
+ +

La relecture technique consiste en une vérification de la véracité des explications techniques de l'article, et à corriger les erreurs qui pourraient s'y trouver. Si un rédacteur de l'article souhaite que quelqu'un d'autre vérifie le contenu technique, le rédacteur coche la case "Technical review" (Relecture technique) lors de l'édition. Souvent le rédacteur contacte un ingénieur particulier pour réaliser la relecture technique, mais n'importe qui avec une expertise technique sur le sujet peut le faire.

+ + + + + + + + + + + + + + + + +
Où cela doit être fait ?Dans les articles qui sont marqués comme nécessitant une relecture technique.
Qu'est ce qu'il faut savoir pour faire cette tâche ? +
    +
  • Expertise sur le sujet couvert par l'article que vous vous apprêtez à relire.
    • +
  • Savoir éditer des articles sur MDN.
    • +
+
Quelles sont les étapes ? +
    +
  1. Allez sur la liste des pages nécessitant une relecture technique.
    2. +
  2. Choisissez une page dont vous connaissez très bien le sujet.
    3. +
  3. Cliquez sur le lien de l'article.
    4. +
  4. Une fois la page chargée, cliquez sur le bouton MODIFIER en haut de l'article ; il vous amènera à l'interface d'édition. N'hésitez pas à changer de page si celle-ci ne vous convient pas.
    5. +
  5. En lisant l'article, corrigez toute information technique erronée, et ajoutez les informations importantes qui seraient absentes.
    6. +
  6. Expliquez ce que vous avez fait, en bas de l'article dans la section "Commentaire sur la révision". (par exemple : "Relecture technique terminée") Si vous avez corrigé des informations pensez à les inclure dans votre commentaire (par exemple : Relecture technique ; correction de la description des paramètres").
    7. +
  7. Cliquer sur le bouton ENREGISTRER LES MODIFICATIONS.
    8. +
  8. Une fois que l'article corrigé apparait à l'écran, après avoir quitté le mode d'édition, cochez l'entrée Technical, sur le côté droit, et cliquez Submit Review.
    9. +
  9. Vous avez fini !
    10. +
+
diff --git a/files/fr/mdn/contribute/howto/index.html b/files/fr/mdn/contribute/howto/index.html new file mode 100644 index 0000000000..59b33bbba6 --- /dev/null +++ b/files/fr/mdn/contribute/howto/index.html @@ -0,0 +1,13 @@ +--- +title: Guides "Comment faire" +slug: MDN/Contribute/Howto +tags: + - Landing + - MDN Meta +translation_of: MDN/Contribute/Howto +--- +
{{MDNSidebar}}
{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Ces articles fournissent des guides pas-à-pas pour la réalisation d'objectifs spécifiques lorsque vous contribuez sur MDN.

+ +

{{LandingPageListSubpages}}

diff --git a/files/fr/mdn/contribute/howto/lier_un_compte_github/index.html b/files/fr/mdn/contribute/howto/lier_un_compte_github/index.html new file mode 100644 index 0000000000..6a3ac68db6 --- /dev/null +++ b/files/fr/mdn/contribute/howto/lier_un_compte_github/index.html @@ -0,0 +1,17 @@ +--- +title: Comment lier un compte GitHub à votre profil MDN +slug: MDN/Contribute/Howto/Lier_un_compte_GitHub +tags: + - Documentation + - MDN + - MDN Meta + - Projet MDN +translation_of: Archive/MDN/Howto_Link_a_Github_account +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +
+

Note: Support for Persona logins on MDN was disabled on November 1, 2016. The method for adding a Github account to your profile therefore no longer works. If you didn't add a GitHub login to your MDN account before we disabled Persona logins, please file an "Account Help" bug on Bugzilla. For further reading about the end of life of Persona, see: Persona shutdown guidelines.

+
diff --git a/files/fr/mdn/contribute/howto/set_the_summary_for_a_page/index.html b/files/fr/mdn/contribute/howto/set_the_summary_for_a_page/index.html new file mode 100644 index 0000000000..eb57ce4229 --- /dev/null +++ b/files/fr/mdn/contribute/howto/set_the_summary_for_a_page/index.html @@ -0,0 +1,60 @@ +--- +title: Comment définir le résumé d'une page +slug: MDN/Contribute/Howto/Set_the_summary_for_a_page +tags: + - Communauté + - Documentation + - Guide + - MDN +translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page +--- +
{{MDNSidebar}}

Vous pouvez définir le resumé d'une page sur MDN, qui pourra être utilisée de diverses manières. Notamment dans les résultats des moteurs de recherches, dans les autres pages MDN ainsi que les pages d'actualités et dans les infobulles.Cela doit être un texte ayant un sens à la fois dans le contexte de la page,  mais également lors de l'affichage dans d'autres contextes, sans le reste du contenu de la page.

+ +

Un résumé peut avoir été explicitement défini dans la page. S'il n'y en a pas, la ou les premières phrases sont alors utilisées, ce qui n'est pas toujours le plus adapté dans ce cas.

+ + + + + + + + + + + + + + + + + + + + +
Quelle est la tâche ?Définir dans la page un texte qui puisse être utilisé comme résumé dans un autre contexte ; cette tâche peut inclure une réécriture adaptée du texte, si nécessaire.
Où est-ce qu'il y en a besoin ?Dans les pages qui n'ont pas de résumé, ou un qui peut être amélioré.
Qu'avez vous besoin de savoir pour la réaliser ?Connaissance de l'éditeur MDN ; de bonnes compétences de rédaction en français ; suffisamment de connaissances dans le sujet de la page, pour pouvoir écrire un bon résumé.
Quelles sont les étapes à réaliser ? +
    +
  1. Choisir une page sur laquelle ajouter un résumé : +
      +
    1. Dans la page du statut de la documentation MDN, cliquer sur un lien de la catégorie Sections qui représente un sujet que vous connaissez (par exemple, HTML) :
      +
      2. +
    2. Dans la page de votre sujet, cliquez sur l'entête Pages dans le tableau Summary. Cela vous redirige vers un index de toutes les pages de ce sujet ; il affiche le lien de la page dans la colonne de gauche. Les tags et résumés dans la colonne de droite :
      +
      3. +
    3. Choisir une page dont le résumé est manquant, ou mauvais :
      +
      4. +
    4. Cliquer sur le lien pour aller sur la page.
      5. +
    +
    2. +
  2. Cliquer sur Modifier pour ouvrir la page dans l'éditeur MDN.
    3. +
  3. Chercher une phrase ou deux qui fonctionnent comme un résumé en dehors du contexte. Si nécessaire, modifier le contenu pour obtenir des phrases adaptées à un résumé.
    4. +
  4. Sélectionner le texte à utiliser comme résumé.
    5. +
  5. Dans le widget Styles de la barre d'outils de l'éditeur, sélectionner SEO Summary. (Dans le code source de la page, cela crée un élément {{HTMLElement("span")}} avec la classe class="seoSummary" autour du texte sélectionné.)
    +
    6. +
  6. Enregistrer vos modifications avec un commentaire de révision du style "Définir le résumé de la page" ou "Set the page summary" (en anglais).
    7. +
+
+ +

 

+ +

 

+ +

 

diff --git a/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html b/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html new file mode 100644 index 0000000000..26c9e08c0e --- /dev/null +++ b/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html @@ -0,0 +1,117 @@ +--- +title: Écrire et référencer une entrée de glossaire +slug: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary +tags: + - Comment… + - Glossaire + - Guide + - MDN Méta(2) +translation_of: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary +--- +
{{MDNSidebar}}
+ +

Le glossaire MDN est le lieu privilégié où nous définissons la terminologie, le jargon et les abréviations utilisés dans la documentation et les codes.  Contribuer à ce glossaire est une moyen simple de rendre le Web plus compréhensible pour n'importe qui. Nul besoin de posséder un haut niveau de compétence pour écrire des entrées du glossaire,  elles doivent rester simples et évidentes.

+ +

Comment créer une entrée

+ +

Pour trouver des sujets ayant besoin d'entrées de glossaire, consultez la liste des termes à documenter à la fin de la page concernant le sujet en question ; cliquez n'importe lequel de ses liens pour commencer une nouvelle page de glossaire, puis suivez les étapes ci-dessous.

+ +

Si vous avez une idée pour une nouvelle entrée de glossaire, cliquez simplement sur le bouton ci-dessous pour ouvrir un nouvel onglet et suivez les étapes décrites sous le bouton :

+

Écrire une nouvelle entrée de glossaire

+ +

 

+ +

Étape 1: écrire un résumé

+ +

Le premier paragraphe d'une page de glossaire consiste en une description courte et simple du terme — de préférence n'exédant pas les deux lignes. Assurez-vous que n'importe qui lisant cette description puisse immédiatement saisir le sens du terme concerné.

+ +
+

Note : ne copiez-collez pas la définition d'un autre endroit (spécialement pas de Wikipédia, puisque leurs licences sont réduites et donc incompatiles avec celles de MDN).

+
+ +
+

Note : il est important également de s'assurer que le contenu est simple et compréhensible. Cela vaut la peine de passer un peu de temps dessus plutôt que de trahir le sens. Ce glossaire doit contenir du contenu nouveau et utile, pas répéter ce que l'on peut trouver partout ailleurs.

+
+ +

Les liens conduisant à cette entrée de glossaire feront apparaitre ce résumé au survol de la souris, de telle sorte que le lecteur pourra obtenir une définition sans avoir à naviguer jusqu'à la page concernée (voyez ci-dessous comment insérer un lien vers une entrée de glossaire avec la macro \{{Glossary}}).

+ +

Si vous y tenez, vous pouvez ajouter quelques paragraphes supplémentaires, mais prenez garde de ne pas vous retrouver à écrire tout un article. Écrire un article complet est une bonne chose, mais ne le placez pas dans le glossaire. Si vous ne savez pas où placer cet article, n'hésitez pas à prendre la parole pour en parler ici.

+ +

Étape 2 : offrir d'autres sources

+ +

Pour terminer, une entrée de glossaire devrait toujours s'achever sur une section « En savoir plus ». Cette section devrait contenir des liens qui aideront le lecteur à aller plus loin : découvrir le sujet plus en détail, apprendre à utiliser la technologie en question, etc.

+ +

Il est recommandé de trier ces liens en au moins trois groupes :

+ +
+
Connaissance générale
+
Liens qui fournissent plus d'information générale ; par exemple, un lien vers Wikipédia est un excellent début.
+
Références techniques
+
Liens vers une information technique plus avancée, sur MDN par exemple.
+
Apprentissage et tutoriels
+
Liens vers des tutoriels, des exercices ou tout autre matériel susceptible d'apprendre au lecteur à maitriser les technologies liées au terme défini.
+
+ +

Termes suggérés

+ +

Vous désirez contribuer mais vous ignorez quel terme doit être défini ? Voici une liste de suggestions. Cliquez un mot et lancez-vous !

+ +

Gérer les ambiguïtés

+ +

Parfois, en fonction du contexte, un même terme peut connaitre plusieurs définitions. Pour traiter ces ambiguïtés, vous devez suivre ce guide :

+ + + +

Illustrons cela par un exemple. Le terme signature peut avoir différentes significations dans au moins trois contextes différents : la sécurité, les fonctions et les mèls.

+ +
    +
  1. La page Glossaire/Signature est la page de « désambiguïsation » avec la macro {{TemplateLink("GlossaryDisambiguation")}} macro.
    2. +
  2. La sous-page Glossaire/Signature/Sécurité est la page définissant le terme dans le contexte de la sécurité informatique.
    3. +
  3. La sous-page Glossaire/Signature/Fonction est la page définissant les signatures de fonction.
    4. +
  4. La sous-page Glossaire/Signature/Mèl est la page définissant les signatures de mèl.
    5. +
+ +

Utiliser la macro \{{Glossary}}

+ +

Le glossaire devient beaucoup plus utile lorsque le lecteur peut atteindre les définitions depuis un autre document sans avoir à  naviguer hors de ce document. C'est la raison pour laquelle nous vous incitons à créer des liens vers le glossaire dès que vous le pouvez, en utilisant la macro {{TemplateLink("Glossary")}} :

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
MacroResultNote
\{{Glossary("browser")}}{{Glossary("browser")}}Quand un terme correspond à un terme à définir, utilisez simplement la macro telle quelle (notez qu'elle est sensible à la casse — minuscule/majuscule)
\{{Glossary("browser", "Web browser")}}{{Glossary("browser","Web browser")}}Fournissez en deuxième argument un texte alternatif à afficher.
\{{Glossary("browser", "Web browser", 1)}}{{Glossary("browser","Web browser",1)}}Optionnellement, entrez le chiffre 1 comme troisième argument pour afficher le lien de façon classique plutôt que comme une mise en exergue subtile.
+ +

Les liens créés avec la macro \{{Glossary}} affichent toujours un texte au survol de la souris, qui contient le résumé de l'entrée du glossaire (cf. ci-dessus).

+ +

Conventions

+ +

Dans la plupart des cas, sur MDN, l'usage de la macro est sûr. Il y a cependant quelques exceptions que vous devez aborder avec précaution :

+ + diff --git a/files/fr/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html b/files/fr/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html new file mode 100644 index 0000000000..5ef97245d0 --- /dev/null +++ b/files/fr/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html @@ -0,0 +1,129 @@ +--- +title: Comment rédiger un article pour aider les gens à se familiariser avec le Web +slug: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web +tags: + - Apprentissage + - Guide + - How to +translation_of: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web +--- +
{{MDNSidebar}}
+ +
+

L'Espace d'apprentissage de MDN est le portail pour les articles qui présentent les concepts Web aux nouveaux développeurs. Parce que son contenu s'adresse surtout aux débutants, c'est un endroit idéal pour partager les connaissances et aider les nouveaux arrivants à connaître le Web. Il est important de s'assurer que les nouveaux développeurs peuvent comprendre ce contenu, c'est pourquoi nous y accordons une attention particulière.

+ +

Cet article explique comment écrire des pages pour l'Espace d'apprentissage.

+
+ +

Comment écrire un article pour l'Espace d'Apprentissage

+ +

 

+ +

Pour commencer à partager vos connaissances, cliquez simplement sur le gros bouton vert, puis parcourez les cinq étapes ci-dessous. Si vous êtes à la recherche d'idées, jetez un coup d'oeil au tableau de notre équipe Trello !

+ +

 

+ +
Écrire un nouvel article pour l'Espace d'Apprentissage + +
 
+
+ +

 

+ +

Cet article ne se retrouvera peut-être pas exactement au bon endroit, mais au moins, il est sur MDN. Si vous avez besoin de parler à quelqu'un pour le mettre au bon endroit, n'hésitez pas à nous contacter.

+ +

Étape n° 1 : écrire un résumé en deux lignes

+ +

La première phrase de l'article doit résumer le sujet que vous allez traiter, et la seconde aborder quelques particularités des éléments mis dans l'article. Par exemple :

+ +
+

Alors que les fichiers {{glossary("HTML")}} contiennent du contenu structuré, les {{Glossary("CSS")}}, autre technologie majeure du Web, donneront au contenu l'apparence souhaitée. Dans cet article, nous allons détailler le fonctionnement de cette technologie et indiquer comment écrire votre propre exemple de base.

+
+ +

Notez comment l'exemple explique brièvement que le CSS est une technologie Web de base utilisée pour styliser les pages. C'est suffisant pour que le lecteur puisse se faire une bonne idée de ce que l'article traite.

+ +

Comme les articles du domaine d'apprentissage s'adressent principalement aux débutants, chaque article doit porter sur un sujet simple afin de ne pas noyer le lecteur sous un flot de concepts nouveaux. Si vous ne pouvez pas résumer l'article en une phrase, il se peut que vous essayiez d'en faire trop en un article !

+ +

Étape n° 2 : ajouter une boîte d'en‑tête

+ +

Ajoutez ensuite une boîte d'en‑tête pour aider les lecteurs à se repérer et savoir où ils en sont dans le processus d'apprentissage.  Voici l'exemple d'une boîte d'en‑tête issue de « Comprendre les URL et leur structure ». Vous pouvez utiliser cet article comme modèle lorsque vous écrivez le vôtre.

+ +

 

+ + + + + + + + + + + + +
Prérequis :Vous devez au préalable savoir comment fonctionne Internet, ce qu'est un serveur web et les concepts sous-jacents aux liens sur le Web.
Objectifs :Savoir ce qu'est une URL et comprendre son rôle sur le Web.
+ +

 

+ +
+
Prérequis
+
Que doit déjà savoir le lecteur pour comprendre l'article ? Lorsque c'est possible, faites de chaque prérequis un lien vers un autre article du domaine d'apprentissage couvrant le concept (à moins qu'il ne s'agisse d'un article vraiment élémentaire qui n'exige aucune connaissance préalable).
+
Objectifs
+
Cette section décrit brièvement ce que le lecteur apprendra à la lecture de cet article. C'est un peu différent du résumé en deux lignes ; ce dernier est le condensé du sujet de l'article, tandis que les objectifs précisent ce que le lecteur peut s'attendre à apprendre à la lecture de l'article.
+
+ +
+

Note : Pour créer ce tableau, vous pouvez, soit faire un copier‑coller de l'exemple ci-dessus, soit utiliser l'outil table de l'éditeur du MDN. Si vous choisissez d'utiliser l'outil table, vous devez spécifiquement ajouter la classe CSS learn‑box en plus de la classe standard‑table par défaut. Pour ce faire, lorsque vous créez ou modifiez les propriétés de la table, allez dans le panneau "Avancé" et réglez le champ Stylesheet Classes sur « standard‑table learn‑box ».

+
+ +

Étape n° 3 : écrire la description complète

+ +

Rédigez ensuite une description plus verbeuse donnant un aperçu plus complet de l'article et en soulignant les concepts les plus importants. N'oubliez pas d'expliquer pourquoi le lecteur doit prendre le temps d'apprendre ce sujet et de lire votre article !

+ +

Étape n° 4 : approfondir

+ +

Quand vous en avez fini avec tout cela, vous pouvez enfin approfondir le sujet. Vous pouvez structurer cette partie de votre article comme vous l'entendez (n'hésitez pas à consulter notre guide de style). C'est votre chance de briller ! Expliquez en détail ce à propos de quoi vous écrivez. Fournissez des liens vers la documentation de référence complète, expliquez en détail le fonctionnement de la technologie, fournissez des détails sur la syntaxe et l'utilisation, et ainsi de suite. C'est à vous de décider !

+ +

Pour vous guider, voici quelques astuces de rédaction pour les débutants :

+ + + +

Jetez un coup d'œil aux premières sections de l'article Fonctions - blocs de code réutilisables pour quelques bonnes descriptions.

+ +

Étape n° 5 : fournir du matériau pour un « apprentissage actif »

+ +

Pour illustrer l'article et aider le lecteur à mieux saisir ce qu'il apprend, faites en sorte de pourvoir des exercices, des tutoriels et des tâches à accomplir. En demandant au lecteur d'utiliser et d'expérimenter activement et de façon pratique les concepts expliqués dans l'article, vous pouvez l'aider à « verrouiller » l'information dans sa tête.

+ +

Vous pouvez choisir d'incorporer les exemples directement dans la page en tant qu'exemples directs ou établir un lien sur eux s'ils ne fonctionnent pas sous la forme précédente. Si vous êtes intéressés par la création de ces éléments de forte valeur, veuillez lire l'article Créer un exercice interactif pour faciliter l'apprentissage du Web.

+ +

Si vous ne pouvez pas fournir de liens vers du matériel d'apprentissage actif existant (vous n'en connaissez pas ou n'avez pas le temps de les créer), vous devriez ajouter une ancre {{Tag("NeedsActiveLearning")}} à l'article. De cette façon, d'autres contributeurs peuvent trouver des articles nécessitant du matériel d'apprentissage actif et peut-être vous aider à les trouver.

+ +

Voyez Apprentissage actif : selection des divers éléments dans le cas d'un exercice d'apprentissage actif ou Apprentissage actif : jouer dans la portée pour un autre style d'exercices : il consiste à faire télécharger localement un canevas et le modifier en suivant des étapes préétablies.

+ +

Étape n° 6 : faire revoir l'article et le mettre au menu de l'Espace d'Apprentissage

+ +

Après avoir écrit l'article, faites-le nous savoir pour que nous puissions en faire la revue et suggérer des améliorations. Encore une fois, voyez notre section Nous contacter pour connaître les meilleures façons d'entrer en contact.

+ +

Pour vraiment terminer votre article, il est nécessaire de le placer dans le menu principal de navigation de l'Espace d'Apprentissage. Ce menu est généré par la macro LearnSidebar : vous aurez besoin de privilèges spéciaux pour la modifier, donc, encore une fois, parlez en à l'une de nos équipes pour qu'il y soit ajouté.

+ +

Enfin, vous devriez ajouter l'accès au menu dans votre page — on effectue cet ajout à l'aide d'un appel à la macro \{{LearnSidebar}}} dans un paragraphe au haut de votre page.

+ + + +

Suggestions d'articles

+ +

Vous souhaitez contribuer, mais vous n'êtes pas sûr du sujet à retenir ?

+ +

L'équipe de l'Espace d'Apprentissage tient un  tableau Trello d'idées d'articles à écrire. Vous êtes libre d'en choisir une et de vous mettre au travail !

+ +

 

+ +

 

diff --git "a/files/fr/mdn/contribute/howto/\303\251tiquettes_pages_javascript/index.html" "b/files/fr/mdn/contribute/howto/\303\251tiquettes_pages_javascript/index.html" new file mode 100644 index 0000000000..93e6a0a105 --- /dev/null +++ "b/files/fr/mdn/contribute/howto/\303\251tiquettes_pages_javascript/index.html" @@ -0,0 +1,74 @@ +--- +title: Comment étiqueter les pages JavaScript +slug: MDN/Contribute/Howto/Étiquettes_pages_JavaScript +tags: + - Guide + - JavaScript + - MDN Meta + - Méthode +translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages +--- +
{{MDNSidebar}}

L'étiquettage (Tagging) consiste à ajouter des méta-informations aux pages pour que leurs contenus puissent être groupés, par exemple dans l'outil de recherche.

+ +
+
Où cela doit-il être fait ?
+
Dans les pages Javascript sans étiquettes.
+
Que devez-vous savoir pour faire cette tâche ?
+
Connaissances basiques en Javascript, comme savoir ce qu'est une méthode ou une propriété.
+
Quelles sont les étapes pour le faire ?
+
+
    +
  1. Choisissez une des pages dans la liste liée ci-dessus.
    2. +
  2. Cliquez sur le lien de l'article pour charger la page.
    3. +
  3. Une fois que la page a été chargée, cliquez sur le bouton MODIFIER près du haut : cela vous placera dans l'éditeur MDN.
    4. +
  4. Au minimum l'étiquette JavaScript devrait être ajoutée. Il y a quelques autres étiquettes possible à ajouter: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ÉtiquetteSur quelle page l'utiliser
    Methodméthodes
    Propertypropriétés
    prototypeprototypes
    Nom du type d'objetméthodes d'objet; par exemple String.fromCharCode doit avoir l'étiquette String
    ECMAScript6 et ExperimentalNouveautés ajoutées dans la nouvelle version de l'ECMAScript
    Deprecatedfonctionnalités dépréciées (dont l'usage n'est pas encouragé mais qui reste supporté)
    Obsoletefonctionnalités obsolètes (lesquelles ne sont plus supportée dans les navigateurs modernes)
    autresVoir MDN tagging standards pour d'autres étiquettes possibles à appliquer
    +
    5. +
  5. Sauvegardez avec un commentaire.
    6. +
  6. Vous avez terminé !
    7. +
+
+
+ +

 

diff --git a/files/fr/mdn/contribute/index.html b/files/fr/mdn/contribute/index.html new file mode 100644 index 0000000000..de661ff607 --- /dev/null +++ b/files/fr/mdn/contribute/index.html @@ -0,0 +1,69 @@ +--- +title: Contribuer au MDN +slug: MDN/Contribute +tags: + - Documentation + - Guide + - Landing + - MDN +translation_of: MDN/Contribute +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/fr/docs/MDN/Contribute")}}
+ +

Bienvenue ! En visitant cette page, vous venez de faire votre premier pas pour devenir un contributeur à MDN.

+ +

Vous trouverez ici des guides qui vous aideront à commencer, des informations sur la façon d'utiliser l'éditeur de texte et ses outils et bien plus encore. Assurez vous d'avoir lu et d'être en accord, avec les conditions d'utilisation de MDN avant de commencer toute modification.

+ +

Si vous n'avez jamais contribué auparavant, le guide en ligne Débuter sur MDN peut vous aider à choisir votre sujet de prédilection et vous fournir de l'aide.

+ +
+
+
+
Guide du style et contenu
+
Le guide du contenu et du style MDN fournit des détails sur le style d’écriture, la mise en forme des pages et le style du contenu, de sorte que ce que vous rédigez soit cohérent avec le reste du contenu de MDN.
+
Guide de l’éditeur
+
Un guide complet sur la façon d’utiliser l’éditeur de MDN.
+
Terminologie et conventions
+
Notre guide sur la terminologie et les conventions fournit des informations afin de vous assurer que vous utilisez la bonne terminologie pour décrire les choses.
+
Travailler avec la communauté MDN
+
Un guide pour travailler avec notre communauté, trouver de l'aide, et se connecter avec les personnes qui ont les réponses à vos questions quand vous contribuez sur MDN.
+
Forum aux questions
+
Astuces et réponses sur les questions les plus courantes concernant la contribution à MDN.
+
+ +
+
Contribuer à Kuma
+
Un guide pour contribuer au projet Kuma. Kuma est la plate-forme qui propulse le site web MDN.
+
+
+ +
+

Comment faire…

+ +

Nos guides comment faire fournissent des instructions étape par étape pour vous aider à accomplir des tâches spécifiques lors de la contribution à MDN.

+ +
+
Comment documenter une propriété CSS
+
Un guide pour rédiger la documentation des propriétés CSS. Toute la documentation sur les propriétes CSS devrait suivre le style et la mise en page décrits dans cet article.
+
Comment documenter un élément HTML
+
Ce guide pour documenter les éléments HTML vous assure que le document que vous écrivez concorde avec les autres sur MDN.
+
Comment étiqueter proprement des pages
+
Ce guide pour étiqueter les pages donne des informations sur nos standards d'étiquetage, incluant des listes d'étiquettes que nous utilisons sur MDN. Suivre ce guide vous assure que votre contenu est correctement classé, plus facilement trouvable et que nos filtres du moteur de recherche fonctionnent avec vos articles.
+
Comment interpréter des spécifications
+
Ce guide vous aidera à interpréter les spécifications standard du Web ; être capable de les lire peut être une forme d'art, et de savoir comment le faire vous aidera à créer une meilleure documentation.
+
+ +

Localisation

+ +
+
Visite guidée de la localisation
+
Cette visite guidée va vous apprendre comment localiser du contenu sur MDN.
+
Guide de la localisation
+
Ce guide fournit des détails sur le processus de localisation du contenu sur MDN.
+
Projets de localisation
+
Trouvez le projet de localisation pour votre langue — ou, s'il n'y en a pas, apprenez comment en démarrer un nouveau !
+
+
+
diff --git a/files/fr/mdn/contribute/localize/index.html b/files/fr/mdn/contribute/localize/index.html new file mode 100644 index 0000000000..ec1bffdb5b --- /dev/null +++ b/files/fr/mdn/contribute/localize/index.html @@ -0,0 +1,29 @@ +--- +title: Localiser MDN +slug: MDN/Contribute/Localize +tags: + - Documentation + - Localisation + - MDN +translation_of: MDN/Contribute/Localize +--- +
{{MDNSidebar}}

MDN est utilisé par des personnes du monde entier comme référence et guide pour les technologies du Web, ainsi qu'au niveau du fonctionnement interne de Firefox. Nos communautés de localisation sont une des clés du projet Mozilla ; leur travail de traduction et de localisation de la documentation aide des personnes, partout dans le monde, à développer pour le Web ouvert. Si vous souhaitez en savoir plus sur nos équipes de localisation, rejoindre une de ces équipes ou simplement démarrer une nouvelle locale, vous êtes à la bonne place.

+ +

{{LandingPageListSubpages}}

+ +

Outils de localisation

+ +

Il y a plusieurs outils qui vous seront utiles pendant votre travail de localisation :

+ +
+
Verbatim
+
Utilisé pour la traduction de chaînes de caractères dans les projets de Mozilla, y compris les interfaces utilisateur de MDN et de Firefox.
+
Transvision
+
Un outil fourni par la communauté Mozilla francophone permettant de rechercher les occurrences d'une chaîne en anglais dans le code des logiciels ou des sites Mozilla, et ainsi de voir les différentes traductions de celle-ci pour une locale donnée. Il est utile pour trouver la traduction adéquate d'un mot ou d'une phrase.
+
+ +

Voir aussi

+ + diff --git a/files/fr/mdn/contribute/localize/translating_pages/index.html b/files/fr/mdn/contribute/localize/translating_pages/index.html new file mode 100644 index 0000000000..805437bf28 --- /dev/null +++ b/files/fr/mdn/contribute/localize/translating_pages/index.html @@ -0,0 +1,51 @@ +--- +title: Traduire les pages MDN +slug: MDN/Contribute/Localize/Translating_pages +tags: + - Guide + - Localisation + - MDN Meta + - l10n +translation_of: MDN/Contribute/Localize/Translating_pages +--- +
{{MDNSidebar}}

Cet article est un guide de base pour traduire le contenu présent sur MDN, incluant à la fois les outils de traduction ainsi que les conseils sur la façon d'utiliser les différents types de contenu.

+ +

Commencer la traduction d'une nouvelle page

+ +

Quand vous rencontrez une page que vous aimeriez traduire dans votre langue, suivez ces étapes :

+ +
    +
  1. Cliquez sur l'icône de Langues ({{FontAwesomeIcon("icon-language")}}) pour ouvrir le menu Langues (ou Languages) et cliquez sur Ajouter une traduction (ou Add a translation). La page qui permet de sélectionner la langue apparaît alors.
    2. +
  2. Sélectionnez la langue dans laquelle vous voulez traduire. L'interface pour traduire l'article s'ouvre avec le texte original affiché sur la vue de gauche.
    3. +
  3. Sous Traduire la description, vous pouvez traduire le titre et optionnellement le permalien dans la langue cible. Le permalien est la dernière partie de l'URL d'une page (par exemple, "Translating_pages" pour cet article). Certaines communautés linguistiques ne traduisent pas le permalien, gardant le même permalien que l'Anglais. Comparez avec d'autres articles dans votre langue pour déterminer la pratique commune. Vous pouvez cliquer sur le signe moins à côté de Traduire la description pour cacher cette information quand vous en avez fini avec elle, pour faire plus de place pour la section Traduire le contenu.
    4. +
  4. Sous Traduire le contenu, traduisez le corps de la page.
    5. +
  5. Laissez au moins une Étiquette pour la page
    6. +
  6. Cliquez sur Enregistrer les modifications lorsque vous avez fini.
    7. +
+ +
Note : les éléments de l'interface utilisateur de la vue Traduction de l'article sont d'abord présentés en anglais. Lors des visites suivantes pour traduire un article en particulier, l'interface utilisateur est affichée dans la langue appropriée si une localisation de MDN est disponible pour cette langue. L'interface utilisateur MDN peut être localisée en utilisant Pontoon. Voir Localiser avec Pontoon pour plus de détails sur la façon d'utiliser cet outil.
+ +

Modifier une page traduite

+ + + +

Si la version anglaise a été modifiée depuis la dernière mise à jour de traduction, la vue concernant la traduction de l'article montre les différentes modifications apportées dans la version anglaise. Cela vous permet de voir ce qui doit être mis à jour dans la traduction.

+ +

Traduire les mots-clés

+ +

Il est important que chaque page soit étiquetée avec au moins un mot-clé. Même s'il s'agit de la traduction. On utilise en général les mêmes étiquettes entre une page en anglais et une page localisée.

+ +

Certaines étiquettes sont utilisées pour les filtres de recherche, ou comme conventions entre les contributeurs. Elles ne doivent pas être traduites. Pour connaître ces balises, veuillez lire les règles d'étiquetage. Vous êtes libre de créer des étiquettes traduites pour le contenu d'un groupe si ce n'est pas couvert par l'une des étiquettes standards.

+ +

Astuces pour les nouveaux traducteurs

+ +

Voici une liste de suggestions, si vous débutez dans la traduction sur MDN :

+ + diff --git a/files/fr/mdn/contribute/persona_sign-in/index.html b/files/fr/mdn/contribute/persona_sign-in/index.html new file mode 100644 index 0000000000..158fb3d3c3 --- /dev/null +++ b/files/fr/mdn/contribute/persona_sign-in/index.html @@ -0,0 +1,32 @@ +--- +title: MDN et connexions Persona +slug: MDN/Contribute/Persona_sign-in +tags: + - Documentation + - MDN + - MDN Meta + - Mozilla + - Persona +translation_of: Archive/MDN/Persona_sign-ins +--- +
{{MDNSidebar}}
+

Veuillez lier votre compte GitHub à votre profil MDN dès maintenant afin de pouvoir continuer à vous connecter sur MDN.

+
+ +

À l'heure actuelle, MDN laisse les contributeurs se connecter grâce à deux fournisseurs d'authentification différents : Mozilla Persona et GitHub. À compter du 1er novembre 2016, nous supprimerons Persona en tant qu'option pour ouvrir une session. Par conséqent, vous devez activer l'authentification Github dans votre profil pour ne pas perdre la possibilité d'accéder à MDN.

+ +

Nous reconnaissons qu'il s'agit là d'un désagrément et nous nous en excusons. Malheureusement, cela ne dépend pas de nous.

+ +

Pourquoi Persona est sur le point d'être supprimé ?

+ +

Mozilla a fermé le projet Persona et ses serveurs seront coupés en novembre 2016. Vous pouvez en apprendre davantage sur la décision de Mozilla d'arrêter Persona en allant sur le wiki de Mozilla.

+ +

Quand sera supprimé Persona ?

+ +

Nous désactiverons Persona en tant que fournisseur d'authentication le 1er novembre 2016 ; en d'autres termes, le 31 octobre 2016 sera le dernier jour où vous pourrez vous connecter sur MDN en utilisant Persona. Nous allons publier à partir de maintenant des notifications de plus en plus urgentes et de plus en plus souvent pour l'ajout de compte GitHub à votre profil MDN. Faîtes-le dès que possible pour éviter tout risque de perdre l'accès à votre compte MDN.

+ +

Est-ce-que MDN proposera un autre fournisseur d'authentification ?

+ +

Nous aimerions beaucoup faire ainsi mais nous n'avons pas encore identifié d'autre fournisseur qui corresponde à nos critères ; de plus, nous ne disposons pas actuellement des ressources développeurs pour en intégrer un. Pour l'instant, votre seule option pour conserver votre accès contributeur à MDN est de lier votre profil MDN à votre compte GitHub.

+ +

Bien sûr, gardez à l'esprit que vous n'avez pas besoin de vous identifier sur MDN pour lire nos contenus. Par contre, si vous avez un compte pour participer et que vous souhaitez pouvoir contribuer de temps en temps à l'avenir, assurez-vous d'ajouter un compte GitHub à votre profil dès que vous le pourrez, avant le 31 octobre 2016.

diff --git a/files/fr/mdn/contribute/processes/index.html b/files/fr/mdn/contribute/processes/index.html new file mode 100644 index 0000000000..bd5eb07d2a --- /dev/null +++ b/files/fr/mdn/contribute/processes/index.html @@ -0,0 +1,17 @@ +--- +title: Documentation processes +slug: MDN/Contribute/Processes +tags: + - Landing + - MDN Meta + - Processes + - TopicStub +translation_of: MDN/Contribute/Processes +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Le projet de documentation MDN est énorme; il y a un grand nombre de technologies à couvrir et nous avons des centaines de contributeurs dans le monde entier. Pour aider à mettre de l'ordre dans le chaos, nous avons des processus standard à suivre lorsque vous travaillez sur des tâches spécifiques liées à la documentation. Vous trouverez ici des guides sur ces processus.

+ +

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/editor/basics/index.html b/files/fr/mdn/editor/basics/index.html new file mode 100644 index 0000000000..4fda34d601 --- /dev/null +++ b/files/fr/mdn/editor/basics/index.html @@ -0,0 +1,74 @@ +--- +title: Editor UI elements +slug: MDN/Editor/Basics +tags: + - Beginner + - Documentation + - Guide + - MDN + - MDN Meta + - NeedsTranslation + - TopicStub + - editor +translation_of: MDN/Editor/Basics +--- +
{{MDNSidebar}}
+ +

L'éditeur WYSIWYG intégré sur MDN est conçu pour rendre aussi facile que possible la création, la modification et l'amélioration d'articles et d'autres pages presque partout sur le site. La fenêtre de l'éditeur, illustrée ci-dessous, se compose de huit zones clés. Ce guide fournit des informations sur chaque section afin que vous sachiez comment utiliser l'ensemble de notre environnement d'édition.

+ +
+

Nous travaillons constamment sur des améliorations à MDN, il y aura donc des moments où cette documentation ou les captures d'écran ci-dessous peuvent être légèrement obsolètes. Cependant, nous mettrons régulièrement à jour cette documentation pour éviter qu'elle ne soit anormalement en retard.

+
+ +

Screenshot of the editor UI (August 2017) with each section labeled

+ +

L'interface utilisateur de l'éditeur contient les sections suivantes, comme indiqué ci-dessus. Cliquez sur un lien ci-dessous pour en savoir plus sur cette section de l'éditeur.

+ + + +

Edit box

+ +

The edit box is, of course, where you actually do your writing.

+ +

Right-clicking in the editor box offers appropriate additional options depending on the context of your click: right-clicking in a table offers table-related options and right-clicking in a list offers list-related options, for example. By default, the editor uses its own contextual menu when you right-click on the editor. To access your browser's default contextual menu (such as to access the Firefox spell checker's list of suggested corrections), hold down the Shift or Control key (the Command key on Mac OS X) while clicking.

+ +

When working in the edit box, you can use its keyboard shortcuts.

+ +

Revision comment

+ +

After you've made your changes, it's strongly recommended you add a comment to your revision. This is displayed in the revision history for the page, as well as on the Revision Dashboard. It helps to explain or justify your changes to others that may review your work later. To add a revision comment, simply type the note into the revision comment box before clicking either of the Publish buttons at the top or bottom of the page.

+ +

There are a few reasons this is helpful:

+ + + +

Review requests

+ +

The MDN community uses reviews to try to monitor and improve the quality of MDN's content. This works by setting a flag on an article indicating that a review is needed. You can learn more about technical reviews and editorial review in the How to guides.

+ +

To request a review on the article you've worked on, toggle on the checkbox next to the type of review that's needed. Technical reviews should be requested any time you make changes to the explanation of how something technical works, while editorial reviews are a good idea when you've made changes and would like someone to review your writing and style choices.

+ +

While selecting a review checkbox adds the article to the lists of those needing technical review or needing editorial review, it does not guarantee that anyone will immediately review the article. For technical reviews, it's a good idea to directly contact a subject-matter expert in the relevant technical area. For editorial reviews, you can post in the MDN discussion forum to request that someone review your changes.

+ +

Be sure to click one of the Publish buttons after making your selections, to commit your review request.

+ +

Voir aussi

+ + + + diff --git a/files/fr/mdn/editor/basics/pieces_jointes/index.html b/files/fr/mdn/editor/basics/pieces_jointes/index.html new file mode 100644 index 0000000000..ad2c850716 --- /dev/null +++ b/files/fr/mdn/editor/basics/pieces_jointes/index.html @@ -0,0 +1,74 @@ +--- +title: Les pièces jointes dans l’éditeur MDN +slug: MDN/Editor/Basics/Pieces_jointes +tags: + - Débutant + - Guide +translation_of: MDN/Editor/Basics/Attachments +--- +
{{MDNSidebar}}
+ +

La section « Pièces jointes » de l’éditeur MDN vous permet de déposer des fichiers sur MDN pour les utiliser dans le contenu MDN, ainsi que visualiser quels fichiers sont utilisés dans le document en cours.

+ +
+

Cette section n’est visible (en bas de page) uniquement si vous avez les permissions requises pour adjoindre des fichiers aux pages. Les utilisateurs n’obtiennent pas cette permission par défaut, donc si vous en avez besoin prenez contact avec les administrateurs MDN pour demander (en anglais) cette permission.

+
+ +

La section « Pièces jointes » n’est de plus visible que lors de l’édition d’un article existant. Elle n’apparaît pas dans l’éditeur pour un nouvel article.

+ +

Démarche pour les pièces jointes

+ +

La façon dont fonctionne le dépôt de fichiers a pour effet de rafraîchir la page à chaque dépôt. Si vous avez réalisé des modifications non sauvegardées à ce moment-là, elles pourront être perdues. C’est donc une bonne idée de sauvegarder vos modifications en cours préalablement au dépôt de fichiers.

+ +

Une bonne démarche est donc la suivante :

+ +
    +
  1. Faites vos modifications, en insérant des textes bouche-trous aux emplacements où vous voulez insérer des images ;
    2. +
  2. Sauvegardez vos modifications ;
    3. +
  3. Adjoindre vos images ;
    4. +
  4. Insérez les images à la place des bouche-trous ;
    5. +
  5. Sauvegardez votre travail à nouveau par sécurité.
    6. +
+ +

Si vous avez des modifications non publiées quand vous déposez une pièce jointe, elles peuvent avoir été sauvegardées comme brouillon, que vous pouvez récupérer en cliquant sur le lien Restore draft / Récupérer le brouillon en haut de la zone d’édition. Ou vous pouvez activer Publish and Keep Editing / Publier et poursuivre l’édition avant de déposer une pièce jointe. Elles peuvent être perdues si vous les laissez en suspens trop longtemps ou si vous oubliez de les récupérer d’une façon ou d’une autre, nous vous recommandons donc la démarche ci-dessus.

+ +

L’IU « Pièces jointes »

+ +

Pour adjoindre une pièce jointe à une page, activez par clic ou clavier le bouton Envoyer des fichiers ; cette action a pour effet de déployer la section de dépôt de fichier qui ressemble à :

+ +

Section « Pièces jointes » déployée après appui du bouton « Envoyer des fichiers », vide. Disposition en tableau avec des colonnes Fichier, Titre, Description, Commentaires avec champs correspondants, vides. Suivi d’un bouton Upload / Dépôt.

+ +

Comme vous pouvez le voir, cette section se présente sous forme d’un tableau qui vous permet de sélectionner un fichier puis lui donner un intitulé, et éventuellement fournir une description et un commentaire éditorial. Quand les champs sont remplis et que vous avez sélectionné votre fichier, activez par clic ou clavier le bouton Upload / Déposer pour l’envoyer sur MDN.

+ +

Le cas d’utilisation le plus commun pour les pièces jointes est d’ajouter des images à des pages. Quand vous déposez une image, assurez-vous s’il vous plaît d’utiliser un outil d’optimisation pour rendre le fichier le plus léger à télécharger que possible. Cela améliore le temps de chargement de la page et augmente globalement la performance de MDN. Vous pouvez utiliser votre outil préféré, si vous en avez un. Sinon nous vous suggérons d’utiliser TinyPNG, en tant qu’outil convivial.

+ +
+

Seule une sélection de formats de fichiers est autorisée comme pièces jointes sur MDN : GIF, JPEG, PNG, et HTML. Les images Photoshop sont autorisées mais devraient être évitées à part dans des cas très particuliers. Tout autre format de fichier est interdit par le formulaire de dépôt. Déposer des fichiers SVG nécessite une autorisation particulière, par conséquent contactez l’équipe rédactionnelle MDN (en anglais) si vous avez besoin de déposer un fichier SVG.

+
+ +

Sentez-vous libre d’ouvrir cette page-ci dans l’éditeur et d’aller jeter un coup d’œil en bas de page à sa liste de pièces jointes pour vous faire une idée.

+ +

Une fois qu’un fichier a été joint, il apparaîtra (par le titre que vous lui avez affecté dans le formulaire de dépôt) dans la boite de dialogue Propriétés de l’image quand vous ajoutez une image à une page. Voir la page MDN Images (en anglais) pour les détails de cette interface.

+ +

Restrictions d’accès

+ +

Il y a un potentiel évident de vandalisme et de pollution en déposant des images qui ne relèvent pas de MDN Web Docs, et par conséquent cet outil n’est pas disponible pour tous les utilisateurs.

+ +

Rôles qui possède cette capacité

+ + + +

Conditions pour obtenir cette capacité

+ +

Vous pouvez obtenir un accès à cet outil si vous réunissez ces conditions :

+ + + +

Voir Demander une élévation de droits (en) pour le processus d’attribution de cette capacité.

diff --git a/files/fr/mdn/editor/index.html b/files/fr/mdn/editor/index.html new file mode 100644 index 0000000000..89f9382092 --- /dev/null +++ b/files/fr/mdn/editor/index.html @@ -0,0 +1,226 @@ +--- +title: Guide du rédacteur +slug: MDN/Editor +tags: + - Projet_MDC +translation_of: MDN/Editor +--- +

{{MDNSidebar}}

+ +

Ce guide du rédacteur est une référence de style pour le Mozilla Developer Center. Il est conçu pour être un ensemble sympathique de bonnes pratiques plutôt qu’une liste de règles stricte, tout ce qui s’y trouve peut donc être ignoré. Ne soyez pas mécontent ou surpris, par contre, si un autre contributeur arrive par la suite avec ses gros sabots et retravaille votre article pour s’y conformer de plus près.

+ +

Naturellement, ce guide s’applique principalement à la traduction française du wiki MDC en anglais. Les traductions dans les autres langues peuvent (et sont encouragées à) avoir leurs propres règles.

+ +

Guides de style recommandés

+ +

Si vous avez des questions concernant l’usage et le style non traitées ici, nous recommandons la consultation du Guide stylistique de Sun. Vous trouverez d’autres guides sur la page qui leur est consacrée sur traduc.org.

+ +

Dictionnaires recommandés

+ +

Pour des questions d’orthographe, outre les dictionnaires papier classiques, vous pouvez vous référer au Grand dictionnaire terminologique de l’OQLF pour les termes techniques, et WordReference pour les autres mots.

+ +

Vous pouvez utiliser l’ancienne ou la nouvelle orthographe, mais essayez de garder la même au sein du même article (ou de la même série d’articles). Utilisez par exemple « évènement » dans la Référence du DOM Gecko. Utilisez toujours des accents sur les majuscules, un mauvais clavier n’est pas une excuse (le correcteur orthographique intégré à Firefox pourra vous y aider).

+ +

Ce guide sera complété au cours du temps, si vous avez des questions particulières qui n’y sont pas traitées, envoyez-les à la liste de discussion ou sur la page de discussion associée à ce guide.

+ +

Nommage des pages et capitalisation des titres

+ + + +

Abréviations latines

+ +

Dans les notes et parenthèses

+ + + +

Dans le texte principal

+ + + +

Signification et équivalents des abréviations latines

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Abrév.LatinFrançais
cf.confervoir
e.g.exempli gratiapar exemple
et al.et aliiet autres
etc.et cæteraet ainsi de suite
i.e.id estc.-à-d., c’est-à-dire, en d’autres mots
N.B.nota beneNotez que…
P.S.post scriptumécrit après
+ +

N.B. Beaucoup de gens confondent « e.g. » avec « i.e. », ne les utilisez donc pas en français.

+ +

Acronymes et abréviations

+ +

Majuscules et points

+ + + +

Expansion

+ + + +
Exceptions
+ + + +

Pluriels d'acronymes ou d'abréviations

+ + + +

Pluriels

+ + + +

Nombres

+ +

Dates

+ + + + + +

Séparateurs de milliers et virgules

+ + + +

Ponctuation

+ +

Espaces et ponctuation

+ + + +

Virgules et énumérations

+ + + +

Autres ressources

+ +

Si vous connaissez d’autres ressources, n’hésitez pas à les ajouter ici.

diff --git a/files/fr/mdn/guidelines/code_lignesdirectrices/index.html b/files/fr/mdn/guidelines/code_lignesdirectrices/index.html new file mode 100644 index 0000000000..325b4fcb88 --- /dev/null +++ b/files/fr/mdn/guidelines/code_lignesdirectrices/index.html @@ -0,0 +1,77 @@ +--- +title: Guide des lignes directrices +slug: MDN/Guidelines/Code_lignesdirectrices +tags: + - CSS + - Code + - Guide + - HTML + - JavaScript + - MDN Meta + - Shell +translation_of: MDN/Guidelines/Code_guidelines +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/fr/docs/MDN")}}
+ +
+

Cette série de documents décrit les directives de codage et les meilleures pratiques que nous utilisons pour écrire des démonstrations, des extraits de code, des exemples interactifs, etc. à utiliser sur MDN.

+ +

Si vous cherchez des lignes directrices à suivre pour rédiger vos exemples de codes, vous êtes au bon endroit. Le plus grand avantage de respecter ces directives est qu'elles favoriseront la cohérence entre nos échantillons et nos démos sur MDN, ce qui augmente la lisibilité et la compréhension en général.

+
+ +
+

Note: Si vous souhaitez obtenir des conseils sur le style du code tel qu'il apparaît sur un article de MDN, plutôt que sur le contenu du code, consultez notre Guide de formatage.

+
+ +

Structure de l'article

+ +

Cet article contient les meilleures pratiques générales de haut niveau pour la rédaction d'exemples de codes MDN. Ses sous-articles sont les suivants :

+ + + +

Meilleures pratiques générales

+ +

Cette section fournit rapidement les meilleures pratiques générales pour créer un échantillon de code minimal compréhensible afin de démontrer l'utilisation d'une caractéristique ou d'une fonction spécifique.

+ +

Les échantillons de code doivent l'être :

+ + + +

Il y a une considération primordiale que vous devez garder à l'esprit : Les lecteurs copieront et colleront l'échantillon de code dans leur propre code, et pourront le mettre en production.

+ +

Par conséquent, vous devez vous assurer que l'exemple de code est utilisable et suit les meilleures pratiques généralement acceptées, et ne fait rien qui puisse rendre une application peu sûre, grossièrement inefficace, gonflée ou inaccessible. Si l'exemple de code n'est pas utilisable ou ne vaut pas la peine d'être produit, veillez à inclure un avertissement dans un commentaire de code et dans le texte explicatif — s'il s'agit d'un extrait et non d'un exemple complet, précisez-le clairement. Cela signifie également que vous devez fournir toutes les informations nécessaires à l'exécution de l'exemple, y compris les dépendances et la configuration.

+ +

Les échantillons de code doivent être aussi autonomes et faciles à comprendre que possible. L'objectif n'est pas nécessairement de produire un code efficace et intelligent qui impressionne les experts et possède une grande fonctionnalité, mais plutôt de produire des exemples de travail réduits qui peuvent être compris le plus rapidement possible.

+ + + +
Lignes directrices :
+ +
+ +
+ +
+ + diff --git a/files/fr/mdn/guidelines/index.html b/files/fr/mdn/guidelines/index.html new file mode 100644 index 0000000000..613181debd --- /dev/null +++ b/files/fr/mdn/guidelines/index.html @@ -0,0 +1,13 @@ +--- +title: Guides du style et du contenu MDN +slug: MDN/Guidelines +tags: + - Documentation + - MDN +translation_of: MDN/Guidelines +--- +
{{MDNSidebar}}
{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Ces guides fournissent des détails sur la manière de rédiger et de présenter la documentation MDN, mais également sur la façon dont les extraits de code et le contenu en général devraient être présentés. En respectant ces guides, vous êtes garantis que ce que vous produisez est propre et facile à utiliser.

+ +

{{LandingPageListSubpages}}

diff --git a/files/fr/mdn/index.html b/files/fr/mdn/index.html new file mode 100644 index 0000000000..ce9fd9e5ab --- /dev/null +++ b/files/fr/mdn/index.html @@ -0,0 +1,37 @@ +--- +title: Le projet MDN +slug: MDN +tags: + - Accueil + - MDN + - MDN Meta +translation_of: MDN +--- +
{{MDNSidebar}}
+ +

Le Mozilla Developer Network (MDN) est un wiki sur lequel sont documentés le Web ouvert, les technologies Mozilla, Firefox OS et d'autres sujets intéressant les développeurs. Nous accueilllons tout le monde pour modifier et ajouter du contenu. Nul besoin d'être un développeur ou de connaître très bien ces technologies. De nombreuses actions sont possibles, des plus simples (comme des relectures et corrections) aux plus complexes (documentation des API).

+ +
+

Le but du projet MDN est de documenter le Web ouvert, les technologies Mozilla et les projets Mozilla. Nous vous invitons à nous aider !

+
+ +

Nous avons besoin de votre aide ! C'est facile. Ne vous souciez pas de demander permission ou d'avoir peur de faire des erreurs. D'autre part, n'hésitez pas à connaître la communauté MDN, nous sommes là pour aider ! La documentation ci-dessous vous aidera à débuter.

+ + + +

Voir aussi

+ + diff --git a/files/fr/mdn/kuma/index.html b/files/fr/mdn/kuma/index.html new file mode 100644 index 0000000000..c9f3813cb2 --- /dev/null +++ b/files/fr/mdn/kuma/index.html @@ -0,0 +1,24 @@ +--- +title: 'Kuma, la plateforme soutenant le wiki MDN' +slug: MDN/Kuma +tags: + - Kuma + - Kuma script + - MDN Meta +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}{{IncludeSubnav("/fr/docs/MDN")}}
+ +

Kuma est le code Django qui alimente le MDN Web Docs.

+ +

{{SubpagesWithSummaries}}

+ +

S'impliquer avec Kuma

+ +

Pour s'engager avec Kuma :

+ + diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/conversations/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/conversations/index.html" new file mode 100644 index 0000000000..70596f8299 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/conversations/index.html" @@ -0,0 +1,56 @@ +--- +title: Discussions de la communauté MDN +slug: MDN/Rejoindre_la_communauté/Conversations +translation_of: MDN/Community/Conversations +--- +
{{MDNSidebar}}

Le travail de MDN se fait beaucoup sur le site MDN mais la communauté est trés active aussi par des discussions (synchrones ou asychrones) se faisant en ligne, par chat ou rencontres organisées.

+ +

Les discussions asynchrones :

+ +

Pour partager des informations et tenir des conversations en direct,  MDN a sa propre catégorie ("MDN") dans le forum Mozilla.  Choisissez cette catégorie pour tous les sujets ayant trait à MDN, y compris le contenu de la documentation, la création, la traduction et la maintenance; la plateforme de développement MDN, et le planning, la définition des objectifs, le suivi des avancées.

+ + + +

Historical archives

+ +

Avant Juin 2017, les discussions de MDN se faisaient par "mailing lists" qui étaient filtrées et archivées avec "Google groups". Si vous voulez voir ces discussions anciennes, regardez dans les "Google groups" correspondants aux vieilles liste de mailings. ( oui, nous savons hélas que ces noms sont  redondants et déroutants. Un accident historique, désolé pour ça...)

+ +
+
mozilla.dev.mdc a.k.a. dev-mdc
+
Cette liste concernait le contenu de la documentation sur MDN.
+
mozilla.dev.mdn a.k.a. dev-mdn
+
Cette liste concernait le travail de développement sur la plateforme MDN  Kuma.
+
mozilla.mdn a.k.a. mdn@
+
Ce forum concernait le planning et l'établissement des priorités de discussions pour le site MDN et autres initiatives associées.
+
+ +

 

+ +

Chat sur IRC

+ +

 

+ +

Internet Relay Chat (IRC) est notre méthode préférée pour le chat quotidien et la discussion en temps réel entre membres de la communauté. Nous utilisons quelques canaux sur le serveur irc.mozilla.org pour les discussions sur MDN.

+ +
+
#mdn
+
This channel is our primary channel for discussing the content of MDN. We talk about writing, organization of content, and so on. We also have "water cooler" conversations here—it's a way our community can keep in touch and just hang out. This is also the place to talk about other aspects of MDN (other than development of the platform), such as Demo Studio, profiles, and so on.
+
#mdndev
+
This channel is where our development team—the people that write the code that makes MDN work—hangs out and discusses their day-to-day work. You're welcome to join in and either participate in the development or simply ask questions about issues you see with the software.
+
+ +

These channels are most likely to be active during weekdays in North America.

+ +

You may want to learn more about IRC and use an installable IRC client such as ChatZilla. It is implemented as a Firefox add-on, which makes it quick and easy to install and use. If you're not familiar with IRC, an easy way to join is using a web-based IRC client such as Mibbit. Here are the direct links to the #mdn and #mdndev channels on Mibbit.

+ +

Join our meetings (and other events)

+ +

The MDN team holds a number of regular meetings that are open to the MDN community. See the MDN Meetings page on the Mozilla wiki for details on the schedule, agendas and notes, and info on how to join.

+ +

See the MDN Events calendar for these and other meetings, local meetups, and other events. The recurring meetings are summarized on the MDN Meetings wiki page.

+ +

If you see a meeting which takes place in the "mdn" channel on our Vidyo videoconferencing system, you can join the conversation on the web.

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/doc_sprints/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/doc_sprints/index.html" new file mode 100644 index 0000000000..8fbfa54cd1 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/doc_sprints/index.html" @@ -0,0 +1,133 @@ +--- +title: Doc sprints +slug: MDN/Rejoindre_la_communauté/Doc_sprints +translation_of: MDN/Community/Doc_sprints +--- +
{{MDNSidebar}}

{{ draft() }}

+ +
+

Remarque: La communauté MDN a souvent tenu des doc sprints au cours de la période 2010-2013. À partir de 2014, ces événements ont été élargis en champ de «Hack on MDN» les événements qui incluent le code de piratage ainsi que des projets de documentation. La plupart des conseils ci-dessous s'applique aussi bien aux "Hack" sprints et qu'aux documentation sprints.

+
+ +

Ceci est un guide pour l'organisation d'un doc sprint. Il contient des conseils et astuces de personnes qui ont organisé les doc sprints, pour vous aider dans l'organisation de celui-ci aussi. Ce guide appuie également sur les idées du livre FLOSS Manuals Book Sprints.

+ +

Qu'est ce qu'un doc sprint?

+ +

Un doc sprint est une courte période où un groupe de personnes se réunissent, virtuellement ou réellement, à collaborer à la rédaction de documentation sur un sujet donné ou des sujets connexes.

+ +

Types de sprints

+ +

Les sprints peuvent être virtuel ou en personne, ou une combinaison. Pour un sprint virtuel, tout le monde participe à partir de là où ils se trouvent, en communiquant  uniquement par le biais des cannaux dédiés. Pour un sprint en personne, les participants se réunissent au même endroit pendant toute la durée du sprint, afin qu'ils puissent communiquer  face-à-face. Les sprints hybrides peuvent être la plupart du temps en personne avec des participants à distance, ou la plupart du temps virtuel avec des rassemblements locaux. En personne les sprints exigent plus de planification logistique, pour assurer le lieu de la reunion , reunir tout le monde dans un même endroit, les loger et les nourrir pendant le sprint.

+ +

Une autre manière de classer par catégorie les sprints focalisés sur des thématiques  . Par exemple, un sprint pourrait se concentrer sur un domaine particulier, tels que le développement Web, ou sur la traduction dans une langue particulière.

+ +

Planification d'un sprint

+ +

Determiner les objectifs

+ +

Ayez une idée claire sur quels sont les objectifs pour le sprint, à la fois pour le contenu et la communauté. Cela permet de conduire votre planification dans les moindres détails.

+ + + +

Décider du type et de la portée

+ +

Basé sur vos objectifs, se prononcer sur le type de sprint (virtuel, en personne, ou une combinaison) et la portée (sur quoi seront focalisés les participants).

+ +

Par exemple, si vous voulez attirer de nouveaux membres de la communauté, un sprint local en personne serait un bon choix, car aucun voyage est impliqué, mais les participants ont l'occasion de se rencontrer. Si vous voulez vous concentrer sur un domaine spécifique, où les contributeurs de contenu sont répartis géographiquement, et se connaissent déjà les uns les autres, alors un virtual sprint peut faire l'affaire.

+ +

Choisissez les dates et heures

+ +

Pour les sprints en personne qui nécessitent un Voyage, nous avons constaté que trois jours (Soit deux jours de week-end et un jour de semaine) est assez suffisant pour pouvoir accomplir  un travail important, sans prendre trop de temps loin de la vie normale de tout le monde. Pour, sprints public, local, en personne, un jour oû vous pouvez expérer avoir le plus de personne pour s'engager. Pour les sprints virtuels, ils se font généralement sur deux jours: un jour de semaine et un jour de week-end. Comme  autre exemple, dans le passé, il y a eu un mini-sprint pour l'écriture et la traduction de documents, chaque mercredi soir dans le bureau Mozilla Paris; il était principalement en personne pour les résidents, mais a également obtenu la participation à distance de Montréal (où il était à l'heure du déjeuner).

+ +

Placer un sprint à la fin d'une conférence à laquelle tout le monde a assisté a bien fonctionné; essayer de lancer un sprint lors d'une conférence à laquelle tout le monde a assisté ne fonctionnait pas si bien. Assurez-vous que les participants aient connaissance du sprint quand ils font leurs plans de conférence, de sorte qu'ils permettent des jours supplémentaires pour le sprint.

+ +

Considérez les fuseaux horaires des participants virtuels; être sûr que vous laissez suffisamment de temps de travail dans chaque fuseau horaire, et vous avez un certain chevauchement lorsque plusieurs zones (comme l'Europe et des Amériques, ou Amériques et en Asie) sont éveillés. Cependant, c'est une réalité que le temps de personne n'est bon pour tout le monde partout.

+ +

Pour les virtual sprints, les rendez-vous peuvent être réglées à moins de 2-3 semaines à l'avance. Pour les in-person sprints, vous devez décider plus à l'avance, afin de laisser le temps aux gens de décider et de faire des arrangements de voyage.

+ +

Promouvoir le sprint

+ +

Vous pouvez faire le sprint ouvert, et inviter le monde, mais vous devriez avoir quelques personnes clés qui vous savez participeront effictivement. Travailler avec eux lors de la sélection des dates, pour vous assurer qu'ils sont disponibles pendant les dates choisies. Si le sprint n'est pas ouvert, alors vous avez besoin seulement d'étendre les invitations; Assurez-vous que chaque invitation est personnelle, expliquant pourquoi cette personne a été spécialement invitée.

+ +
+
+
+
+
+
+
 
+Pour les public sprints, identifier les groupes existants qui ont un intérêt pour le sujet, par exemple: Les groupes meetup développeur Web locaux pour un in-person sprint locale. Envoyer une annonce par quelque canal est approprié pour ce groupe. Assurez-vous de fournir un lien vers une page web avec plus de détails, et inclure un call-to-action pour les gens s'enregistrer pour le sprint. Eventbrite et Lanyrd sont deuw services qui supportent les enregistrements. Pour les événements Mozilla developer,nous avons constaté que près de la moitié des personnes qui s'enregistrent apparaissent effectivement.
+
+
+
+
+
+ +

Utilisez les canaux de médias sociaux qui sont appropriés pour atteindre vos participants cibles. Nous avons constaté que pour les développeurs Web, cela signifie Twitter, suivi par Google Plus, plus que Facebook ou LinkedIn. Cependant, les canaux populaires peuvent varier géographiquement (comme Orkut au Brésil). Faites appel à quelques personnes bien connectées qui ont une forte popularité parmi votre public cible, et leur demander de re-partager vos messages.

+ +

Logistiques pour les in-person sprints

+ +

Les logistiques pour les in-person sprints sont plus grands pour les longs sprint que pour ceux où les participants se deplacent pour assister. Un court sprint ou un sprint seulement reservé aux locaux nécessite relativement moins de support logistique.

+ +

Budget et financement

+ +

Vous devez savoir combien l'événement va coûter, et d'où l'argent va venir.

+ +

Les coûts à considérer dans votre budget incluent:

+ + + +

Certains de ces coûts peuvent être auto-financé par les participants, ce qui signifie qu'ils paient pour leurs propres dépenses. Il existe une variété de façons d'économiser de l'argent, qui sont mentionnés dans les sections suivantes.

+ +

Il peut être possible d'obtenir le parrainage de Mozilla pour financer une partie des coûts de votre événement. Il permet d'avoir une orientation claire pour votre événement, et un plan spécifique et budget. S'il y a un Mozilla Rep dans votre région, travailler avec eux pour demander le budget et butin à travers le programme Reps. Sinon, vous pouvez soumettre une demande d'événements de développement dans Bugzilla.

+ +
+
Site
+
Il y a beaucoup d'options pour un espace de réunion. Si vous êtes dans une ville avec un bureau Mozilla, vous pouvez utiliser l'espace communautaire dans ce bureau. Ailleurs, les options comprennent des salles de réunion dans les bibliothèques, églises, cafés, ou des entreprises où vous avez des contacts. Beaucoup de villes ont maintenant des espaces de coworking qui louent leurs salles de conférence pour un prix raisonnable.
+
Ressources
+
Assurez-vous que votre site a de bonnes tables et des chaises, et une alimentation fiable et un accès Internet. Assis toute la journée sur une mauvaise chaise est non seulement mal à l'aise; il peut conduire à des blessures. Assurez-vous que le nombre de particiapants et leurs ordinateurs et périphériques ne l'emporte pas sur l'alimentation et la bande passante disponible sur Internet. Soyez généreux (mais pas dangereux) avec des cordons d'extension, et, si nécessaire, d'adaptateurs électriques. Un projecteur pour la visualisation partagée peut être très utile. Whiteboards et notes autocollantes sont grands pour le brainstorming et la planification.
+
Voyage
+
Voyage est pertinente que si les particanpts ne sont pas tous à proximité du lieu de sprint. Les stratégies habituelles pour économiser sur Voyage s'appliquent, et ne sont pas spécifiques aux sprints doc.
+
Hébergements
+
Où les particapants restent ne devraient pas être incommodemrnt loin du lieu de la réunion. Il peut être moins cher (et peut-être plus amusant) de diviser le coût d'une maison de vacances ou appartement, plutôt que de payer pour les chambres d'hôtel individuelles. Si vous avez un mélange de visiteurs et des habitants (prêts), les visiteurs peuvent séjourner dans les maisons des membres de la communauté locale.
+
Nourriture
+
Les participants ont besoin de manger! Prendre des dispositions pour la nourriture pendant le sprint, et informer les participants si certains repas ne seront pas organisées. Si le groupe reste dans une maison, vous pouvez économiser de l'argent en achetant et en cuisinant la nourriture plutôt que de sortir pour manger. Même si la nourriture est auto-financée, il peut réduire des tracas de piocher dans un fonds commun pour la nourriture, plutôt que diviser chaque facture de restaurant. Si votre site permet, des collations (certains sains et d'autres non) disponibles entre les repas.
+
Amusement
+
Prenez du temps pour des des activités sociales de non-écriture. Ceux-ci peuvent être informelles, comme aller pour une randonnée ensemble, ou plus formelle, comme une excursion touristique. Sortir de la bière (à la fin de la journée, bien sûr) est généralement un gagnant. D'autre part, ne pas planifier toutes les heures de la vie quotidienne. Tout le monde a besoin d'un temps d'arrêt, en particulier les introvertis.
+
+ +

Pendant le sprint

+ +

Planifier le travail

+ +

 

+ +

Tâches de suivi

+ +

Avoir un moyen de suivre que des tâches doivent être éfféctuées, qui fait quoi, et ce qui a été accompli. Pour les doc sprints MDN, nous utilisons une page wiki pour la planification à l'avance, et une EtherPad pour le suivi des travaux au cours du sprint.

+ +

Souvent, les gens veulent aider, mais ne savent pas par où commencer, et de décider parmi les nombreuses options prend trop d'effort mental. Pour tout participant donné, leur donner quelques tâches possibles ("vous pourriez faire A ou B"); ce qui simplifie leur choix, sans leur faire penser qu'ils sont gérés.

+ +

Collaboration

+ +

L'un des avantages des in-person sprints est que les gens peuvent travailler ensemble de façon dont ils pourraient ne pas être en mesure quand ils ne sont pas au même endroit, par exemple, en travaillant sur des idées ensemble sur un tableau blanc ou par remue-méninges avec notes autocollantes. Pourtant, il existe des possibilités de collaboration et de camaraderie dans tout type de sprint. Chatter via IRC est essentiel pour les virtual sprints, et toujours très utile pour les in-person sprints (par exemple, pour partager des liens). Pour un plus grand sens de la «présence virtuelle», envisager d'utiliser un service de conférence vidéo, tels que Google Hangout.

+ +

En tant qu'organisateur, rechercher les intérêts communs entre les participants et des façon dont ils peuvent travailler ensemble.

+ +

Célébrer les réalisations

+ +

Assurez-vous de prendre le temps de célébrer les réalisations à la fin de l'esprit. Cela donne des participants est une meilleure sensation que lorsque le sprint se termine juste sans résumé. Si possible, avoir des gens une "demo" de ce qu'ils ont fait, même si c'est juste montrer une nouvelle page de l'article.

+ +

En outre, partager les réalisations de sprint par un billet de blog, pour célébrer publiquement aussi bien. Ceci est important pour tout type de sprint, mais surtout pour les virtual sprints, où les participants pourraient ne pas être tous en ligne à la fin officielle du sprint pour une séance de synthèse.

+ +

 

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/index.html" new file mode 100644 index 0000000000..4e97b48397 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/index.html" @@ -0,0 +1,51 @@ +--- +title: Rejoindre la communauté +slug: MDN/Rejoindre_la_communauté +tags: + - Communauté + - Guide + - MDN Meta +translation_of: MDN/Community +--- +
{{MDNSidebar}}
+ +
+

MDN (acronyme anglais pour réseau de développeur Mozilla) est plus qu’un wiki : c’est une communauté de développeurs travaillant ensemble à faire de MDN une ressource exceptionnelle pour les développeurs qui utilisent les technologies libres du Web.

+
+ +

Nous aimerions que vous contribuiez à MDN, mais nous aimerions encore plus que vous participiez à la communauté MDN. Voici comment s’y connecter, en 3 petites étapes :

+ +
    +
  1. Créer un compte MDN.
    2. +
  2. Rejoindre des discussions. ((en) pas encore traduit)
    3. +
  3. Suivre ce qui se passe. ((en) pas encore traduit)
    4. +
+ +

Comment fonctionne la communauté ?

+ +

Les articles suivants décrivent la communauté de MDN.

+ +
+
+
+
Community roles ((en) rôles dans la communauté)
+
Il y a un certain nombre de rôles, au sein de la communauté MDN, qui ont des responsabilités spécifiques.
+
Doc sprints
+
Ceci est un guide pour organiser un « doc sprint ». Il contient des avis et des conseils de personnes qui en ont organisé, pour vous aider si vous souhaitez en faire un.
+
Follow what’s happening ((en) suivre ce qui se passe)
+
MDN vous est présenté par l’article wiki Mozilla Developer Network community (en). Il contient quelques façons de partager des informations sur ce que nous faisons.
+
+ +
+
+
+ +
+
+
MDN community conversations ((en) discussions de la communauté)
+
Le « travail » de MDN se déroule sur le site MDN, mais la « communauté » passe également par des discussions (asynchrones) et des conversations et réunions en ligne (synchrones).
+
Working in community ((en) travailler dans la communauté)
+
Une partie importante de la contribution à la documentation MDN, à une échelle significative, est de savoir comment travailler dans le cadre de la communauté MDN. Cet article offre des conseils pour vous aider à tirer le meilleur parti de vos interactions avec les autres auteurs et avec les équipes de développement.
+
+
+
diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/roles/admins/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/admins/index.html" new file mode 100644 index 0000000000..8156651aef --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/admins/index.html" @@ -0,0 +1,57 @@ +--- +title: Rôle d'administrateur MDN +slug: MDN/Rejoindre_la_communauté/Roles/Admins +tags: + - Communauté + - Guide + - MDN Meta +translation_of: MDN/Community/Roles/Admins +--- +
{{MDNSidebar}}
+ +

Parmi les rôles sur MDN, le rôle d'administrateur, ou admin, est celui avec le niveau d'autorisation le plus élevé. Les administrateurs peuvent utiliser toutes les fonctionnalités de la plate-forme du site, et même avoir un accès limité aux structures de données en coulisses. Cet article décrit ce que les administrateurs peuvent faire et comment vous pouvez en parler à l'un d'eux pour obtenir de l'aide sur l'une de ces choses.

+ +

Contacter les administrateurs

+ +

Vous pouvez envoyer un e-mail à mdn-admins@mozilla.org pour envoyer un message à l'équipe d'administration.

+ +

Pouvoirs administratifs

+ +

Les administrateurs ont un certain nombre de capacités spéciales. Parmi eux:

+ +

Déplacer les pages

+ +

Tous les administrateurs ont la possibilité de déplacer des pages et des arbres de pages.

+ +

Supprimer des pages

+ +

Tous les administrateurs ont la possibilité de supprimer n'importe quel page du wiki de MDN. Cependant, si vous voulez généralement supprimer une page, vous devez simplement ajouter la balise "junk" à la page. Ne modifiez pas ou n'effacez pas le contenu (cela rend plus diffcile de vérifier si la page doit réellement être supprimée). S'il y a un problème particulièrement majeur (contenu très offensant, par exemple), contactez également un administrateur directement.

+ +

Les administrateurs ont également la possibilité d'annuler la suppression des pages précédemment supprimées (du moins jusqu'à ce qu'elles soient purgées du système, ce qui se produit quelque temps après la suppression). Si vous constatez qu'une page a été supprimée de manière incorrecte, contactez un administrateur.

+ +

Accorder et supprimer des autorisations

+ +

Les administrateurs peuvent modifier les autorisations des utilisateurs. Il y a un processus derrière cela; voir Outils à accès restreint pour plus d'informations.

+ +

Bannir et débannir des utilisateurs

+ +

Parfois, les utilisateurs causent suffisamment de problèmes pour ne pas pouvoir modifier le contenu sur MDN (temporairement ou définitivement). Les administrateurs (ainsi que les conducteurs de sujet et les chefs d'équipe de localisation) ont la possibilité de bannir les utilisateurs, ainsi que de supprimer les bannissements existants.

+ +

Créer/modifier des zones

+ +

Les administrateurs MDN peuvent créer de nouvelles zones, transformer des pages existantes en zones et modifier les informations de zone et le CSS. Pour plus d'informations sur les zones, consultez le guide Zone administration.

+ +

Modifier les informations utilisateur

+ +

Les administrateurs MDN ont une capacité limitée à modifier les informations utilisateur pour lesquelles il n'existe pas encore d'interface utilisateur pour l'édition. Si vous avez besoin de modifier votre nom d'utilisateur, une adresse e-mail associée à un ancien compte MDN "hérité", ou autre, vous pouvez essayer de contacter un administrateur pour obtenir de l'aide. Nous ne promettons pas de pouvoir vous aider; toutes les demandes ne peuvent pas être satisfaites.

+ +

Ajouter ou modifier des entrées de calendrier

+ +

Les administrateurs MDN peuvent mettre à jour ou ajouter au calendrier des événements MDN. Si votre équipe de rédaction a une réunion que vous souhaitez répertorier, ou si vous constatez un problème avec un événement existant, veuillez en informer les administrateurs et nous nous en occuperons.

+ +

Voir aussi

+ + diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/roles/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/index.html" new file mode 100644 index 0000000000..97840b7f4b --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/index.html" @@ -0,0 +1,13 @@ +--- +title: Rôles communautaires +slug: MDN/Rejoindre_la_communauté/Roles +tags: + - Communauté + - MDN Meta +translation_of: MDN/Community/Roles +--- +
{{MDNSidebar}}
+ +

Il existe un certain nombre de rôles au sein de la communauté MDN qui ont des responsabilités spécifiques.

+ +

{{LandingPageListSubPages()}}

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_de_pilote_de_localisation/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_de_pilote_de_localisation/index.html" new file mode 100644 index 0000000000..105be2daea --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_de_pilote_de_localisation/index.html" @@ -0,0 +1,71 @@ +--- +title: Rôle de conducteur de localisation +slug: MDN/Rejoindre_la_communauté/Roles/role_de_pilote_de_localisation +tags: + - Communauté + - Guide + - MDN Meta + - l10n +translation_of: MDN/Community/Roles/Localization_driver_role +--- +
{{MDNSidebar}}
+ +

Un conducteur de localisation MDN coordonne et dirige les activités de documentation sur MDN pour une langue ou des paramètres régionaux particuliers. Ils restent informés de la structure de la documentation dans le MDN, des intérêts des traducteurs et de Mozilla. Ils n'ont pas à faire tous les travaux de traduction liés à leur région eux-mêmes, et en fait, ils sont encouragés à rassembler un groupe de contributeurs intéressés par la traduction et à coordonner les tâches au sein du groupe. Consultez la page Projets de localisation pour une liste des paramètres régionaux actifs et des conducteurs l10n actuels.

+ +

Pourquoi être un conducteur de localisation ?

+ +

Être un conducteur l10n offre l'opportunité d'être ou de s'immerger profondément dans la communauté, et d'avoir un fort impact sur la façon dont Mozilla est perçu dans votre communauté linguistique. Vous pouvez utiliser cette expertise dans votre emploi actuel ou pour vous aider à atteindre un autre emploi.

+ +

De plus, en tant que conducteur l10n, vous pouvez être un moteur pour améliorer la qualité du Web.

+ +

Devenir conducteur l10n

+ +

Pour devenir un conducteur l10n pour une localité qui n'en a pas encore, vous devez d'abord remplir certaines qualifications :

+ + + +

La meilleure façon de le devenir est d'agir comme suit : la plupart des tâches d'un conducteur l10n ne nécessitent pas de pouvoirs ou d'approbations spéciales.

+ +

Une fois que vous avez satisfait à ces exigences, vous pouvez publier sur le forum de discussion MDN que vous souhaitez devenir le conducteur pour une localité donnée, avec une explication de ce qui doit être fait pour cette localité et un aperçu de vos qualifications. Si vous remplissez les conditions requises, nous travaillerons avec vous pour vous aider à vous installer et à vous former aux bases de l'utilisation des nouveaux privilèges à votre disposition.

+ +

Aider un conducteur l10n existant

+ +

Nous ne limitons pas le nombre de conducteur l10n par localité. Bien sûr, ils doivent pouvoir travailler ensemble. :-) Alors n'hésitez pas à les aider : aider à surveiller le contenu pour les spams, les erreurs, etc ; la révision d'articles nouvellements traduits et la mise à jour d'articles déjà traduits sont d'autress tâches possibles.

+ +

Responsabilités

+ +

Le rôle de conducteur l10n s'accompagne d'un certain nombre de responsabilités importantes. Parmi eux:

+ + + +

Privilèges

+ +

En plus des privilèges disponibles pour tous les utilisateurs authentifiées sur MDN (comme l'annulation des modifications, les conducteurs l10n ont ces privilèges supplémentaires :

+ + + +

Nous prévoyons d'ajouter de nouveaux privilèges à l'avenir, comme l'accès à la liste des contributeurs ou la possibilité de bannir les spammeurs.

+ +

Quitter le rôle

+ +

Une fois que vous êtes devenu un conducteur l10n, vous n'avez pas à rester indéfiniment dans ce rôle. Votre intérêt, vos priorités, et votre temps disponible peuvent changer, et c'est OK. Si vous prévoyez de ne pas continuer en tant que conducteur l10n (ou si vous vous rendez compte que vous vous êtes déjà arrêté), veuillez suivre les étapes suivantes :

+ + + +

Si vous n'avez pas été actif sur MDN (ou sur le forum de discussion MDN) depuis deux mois, vous pourriez être contacté pour confirmer que vous souhaitez continuer en tant que conducteur l10n. Les conducteurs L10n qui sont inactifs pendant trois mois, ou qui ne répondent pas dans un délai raisonnable lorsqu'ils sont contactés, peuvent être démis de leurs fonctions.

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_conducteur_de_sujet/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_conducteur_de_sujet/index.html" new file mode 100644 index 0000000000..e1e997fbf7 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_conducteur_de_sujet/index.html" @@ -0,0 +1,82 @@ +--- +title: Rôle du conducteur de sujet +slug: MDN/Rejoindre_la_communauté/Roles/role_du_conducteur_de_sujet +tags: + - Communauté + - Guide + - MDN Meta + - Roles(2) +translation_of: MDN/Community/Roles/Topic_driver_role +--- +
{{MDNSidebar}}
+ +

Un conducteur de sujet MDN coordonne et dirige les activités de documentation sur MDN pour un domaine particulier. Il restent informés des nouveaux développements dans leur domaine, que ce soit au sein de Mozilla, des organismes de normalisation ou d'autres entreprises technologiques, selon le cas. Ils n'ont pas à faire tout le travail de documentation lié à leur sujet eux-mêmes, et en fait, ils sont encouragés à rassembler un groupe de contributeurs intéressés par le sujet et à déléguer des tâches au sein du groupe. Reportez-vous à la page des sujets de Documentation et des conservateurs pour savoir qui est responsable de chaque thème sur MDN.

+ +

Pourquoir être un conducteur de sujet?

+ +

Être un conducteur de sujet offre une opportunité d'être ou de devenir profondément immergé dans un sujet et d'avoir un fort impact sur la façon dont cee sujet est présenté sur MDN. Vous pouvez utiliser cette expertise dans votre emploi actuel ou pour vous aider à atteindre un autre emploi.

+ +

De plus, en tant que conducteur de sujet, vous pouvez être une force motrice pour améliorer la qualité du Web.

+ +

Devenir un conducteur de sujet

+ +

Pour devenir un conducteur de sujet pour un sujet qui n'en a pas encore, vous devez d'abord remplir certaines conditions:

+ + + +

Une fois que vous avez satisfait à ces exigences, vous pouvez publier sur le forum de discussion MDN que vous souhaitez devenir le conducteur pour un sujet donné, avec une explication du sujet que vous aimeriez conduire et un aperçu de vos qualifications. Si vous remplissez les conditions requises, nous travaillerons avec vous pour vous aider à vous installer et à vous former aux bases de l'utilisation des nouveaux privilèges à votre disposition.

+ +
+

Astuce: Si un sujet n'a pas de conducteur de sujet et que vous souhaitez devenir le conducteur du sujet, commencez simplement à agir comme le conducteur de ce sujet ! Si vous faites du bon travail, vous pouvez pratiquement être assuré que nous vous supplierons de rester dans le rôle !

+
+ +

Aider un conducteur de rubrique existant

+ +

Pour les sujets qui ont déjà des conducteurs, vous pouvez toujours être d'une grande aide! La plupart des sujets sont suffisamment vastes et larges pour que de nombreuses personnes contribuent à la documentation et à l'exemple de code soit d'un avantage incroyable. En fait, avoir plusieurs points de vue sur un sujet va presque certainement améliorer la couverture globale du sujet.

+ + + +

Les conducteurs de sujet sont-ils différents des mentors?

+ +

Les deux rôles sont très proches et ont le même genre de privilèges et de responsabilités. La différence réside principalement dans leur engagement. Pour un sujet donné, les conducteurs de sujet dirigent la documentation et son contenu où les mentors soutiennent et responsabilisent la communauté de contributeurs autour de ce sujet. Ils sont complémentaires et travaillent main dans la main la plupart du temps.

+ +

Responsabilités

+ +

Le rôle de conducteur de sujet comporte un certain nombre de responsabilités importantes. Parmi eux:

+ + + +

Privilèges

+ +

En plus des privilèges disponibles pour tous les utilisateurs authentifiés sur MDN (tels que l'annulation des modifications, les conducteurs de sujets ont ces privilèges supplémentaires:

+ + + +

Quitter le rôle

+ +

Une fois que vous êtes devenu un conducteur de sujet, vous n'êtes pas obligé de rester indéfiniment dans ce rôle. Vos intérêts, vos priorités et votre temps disponible peuvent changer, et c'est OK. Si vous prévoyez de ne pas continuer en tant que conducteur de sujet (ou si vous vous rendez compte que vous vous êtes déjà arrêté), veuillez suivre les étapes suivantes:

+ + + +

Si vous n'avez pas été actif sur MDN (ou sur le forum de discussion) depuis deux mois, vous pourriez être contacté pour confirmer que vous souhaitez continuer en tant que conducteur de sujet. Les conducteurs de sujet qui sont inactifs pendant trois mois, ou qui ne répondent pas dans un délai raisonnable lorsqu'ils sont contactés, peuvent être démis de leurs fonctions.

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_mentor/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_mentor/index.html" new file mode 100644 index 0000000000..f77b845b88 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/roles/role_du_mentor/index.html" @@ -0,0 +1,64 @@ +--- +title: Rôle du mentor +slug: MDN/Rejoindre_la_communauté/Roles/role_du_mentor +tags: + - Communauté + - Guide + - MDN Meta +translation_of: MDN/Community/Roles/Mentor_role +--- +
{{MDNSidebar}}
+ +

Un mentor MDN est une personne engagée à aider les nouveaux contributeurs dans un domaine particulier et à diriger le travail de documentation sur MDN dans ce domaine. Les mentors restent informés des priorités et des activités de contribution dans leur domaine. Ils n'ont pas à faire tout le travail de documentation lié à leur sujet eux-mêmes, et en fait, ils s'engagent à rassembler un groupe de contributeurs intéressés par le sujet, à déléguer des tâches au sein du groupe et à aider à responsabiliser les nouveaux contributeurs.

+ +

Devenir mentor

+ +

Pour devenir mentor sur un sujet, vous devez d'abord répondre à certaines qualifications:

+ + + +

Une fois que vous avez rempli ces conditions, vous pouvez publier sur le forum de discussion MDN que vous souhaitez devenir le mentor pour un sujet donné, avec une explication du sujet que vous aimeriez encadrer et un aperçu de vos qualifications. Si vous remplissez les conditions requises, nous travaillerons avec vous pour vous mettre en place et vous former aux bases de l'utilisation des nouveaux privilèges à votre disposition.

+ +
+

Astuce: Si vous voulez devenir mentor, commencez simplement à agir comme tel ! Si vous faites du bon travail, vous pouvez pratiquement être assuré que nous vous supplierons de rester dans le rôle !

+
+ +

Les mentors sont-ils différents des conducteurs de sujet?

+ +

Les deux rôles sont très proches et ont des privilèges et des responsabilités similaires. La différence réside principalement dans leur engagement. Pour un sujet donné, les conducteurs de sujet dirigent la documentation et son contenu où les mentors soutiennent et responsabilisent la communauté de contributeurs autour de ce sujet. Les deux rôles sont complémentaires et travaillent main dans la main la plupart du temps.

+ +

Responsabilités

+ +

Le rôle de mentor s'accompagne d'un certain nombre de responsabilités importantes. Parmi eux:

+ + + +

Privilèges

+ +

En plus des privilèges disponibles pour tous les utilisateurs authentifiés sur MDN, les mentors ont ces privilèges supplémentaires:

+ + + +

Quitter le rôle

+ +

Une fois que vous êtes devenu mentor, vous n'êtes pas obligé de rester indéfiniment dans ce rôle. Votre intérêt, vos priorités et votre temps disponible peuvent changer, et c'est OK. Si vous prévoyez de ne pas continuer en tant que mentor (ou si vous réalisez que vous avez déjà arrêté), veuillez suivre les étapes suivantes:

+ + + +

Si vous n'avez pas été actif sur MDN (ou sur le forum de discussion MDN) depuis deux mois, vous pourriez être contacté pour confirmer que vous souhaitez continuer en tant que mentor. Les mentors qui sont inactifs pendant trois mois, ou qui ne répondent pas dans un délai raisonnable lorsqu'ils sont contactés, peuvent être démis de leurs fonctions.

diff --git "a/files/fr/mdn/rejoindre_la_communaut\303\251/whats_happening/index.html" "b/files/fr/mdn/rejoindre_la_communaut\303\251/whats_happening/index.html" new file mode 100644 index 0000000000..8aba56f330 --- /dev/null +++ "b/files/fr/mdn/rejoindre_la_communaut\303\251/whats_happening/index.html" @@ -0,0 +1,42 @@ +--- +title: Suivez ce qui se passe +slug: MDN/Rejoindre_la_communauté/Whats_happening +tags: + - Communauté + - Débutant + - Guide + - MDN Meta +translation_of: MDN/Community/Whats_happening +--- +
{{MDNSidebar}}
+ +

MDN vous est présenté par la communauté MDN. Voici quelques façons dont nous partageons des informations sur ce que nous faisons.

+ +

Blogs

+ +
+
Mozilla Hacks
+
Actualités à propos et couverture approfondie des technologies et fonctionnalités Web et Mozilla.
+
Engageant les Développeurs
+
Promouvoir l'activité et la discussion au sein de la communauté impliquée dans MDN chez Mozilla.
+
+ +

Flux d'éphémères

+ + + +

Tableaux d'état et tableaux de bord

+ +

Consultez les pages d'état de la documentation pour voir ce qui se passe dans toute l'étendue du contenue MDN. Vous pourrez voir quels articles doivent être écrits ou mis à jour, quels sujets ont le plus besoin d'aide, et bien plus encore.

+ +

Réunions MDN

+ +

Il y a un certain nombre de réunions régulières pour suivre et partager les progrès de divers porjets et processus liés au MDN. Celles-ci sont décrites sur la page wiki des réunions MDN.

+ +

Pour avoir une idée générale de ce qui se passe, la meilleure réunion à laquelle participer est la réunion de la communauté MDN, qui a lieu toutes les deux semaines le mercredi à 10:00, heure du Pacifique (UTC-0800 Octobre-Mars, UTC-0700 en Mars-Octobre), dans le canal IRC #mdn. Voir la page wiki des réunions de la communauté MDN pour les agendas et les notes des réunions précédentes.

+ +

Le calendrier des Événements MDN Publics contient des réunions de la communauté MDN, des sprints de doc, et d'autres événements liés à MDN. Si vous voyez une réunion qui a lieu dans le canal "mdn" sur notre système de visioconférence Vidyo, vous pouvez rejoindre la conversation sur le web.

diff --git a/files/fr/mdn/structures/exemples_live/index.html b/files/fr/mdn/structures/exemples_live/index.html new file mode 100644 index 0000000000..7645a89375 --- /dev/null +++ b/files/fr/mdn/structures/exemples_live/index.html @@ -0,0 +1,250 @@ +--- +title: Exemples live +slug: MDN/Structures/Exemples_live +tags: + - Débutant + - Guide + - MDN + - MDN Meta +translation_of: MDN/Structures/Live_samples +--- +
{{MDNSidebar}}
+ +

MDN permet de transformer les exemples présentés dans les articles en exemples dit "live" qui permettent aux lecteurs de les voir en action. Les exemples live peuvent inclure du HTML, CSS et JavaScript. A noter, les exemples lives ne sont pas intéractifs; néanmoins, ils assurent que le code de sortie affiché pour un exemple est bien le même que défini par l'exemple, parce que la sortie est générée par le code d'exemple.

+ +

Comment le système d'exemples lives fonctionne-t-il ?

+ +

Le système d'exemple live rassemble tout le code existant et le fusionne dans un fichier HTML, puis affiche ce fichier dans une {{HTMLElement("iframe")}}. Un exemple live est composé de deux parties : 

+ + + +

A "group" of code blocks, in this context, is identified by the ID of a heading or a block element (such as a {{HTMLElement("div")}}).

+ + + +

The macro uses a special URL to fetch the sample code for a given group: http://url-of-page$samples/group-id, where group-id is the ID of the heading or block where the code is located. The resulting frame (or page) is sandboxed, secure, and technically may do anything that works on the Web. Of course, as a practical matter, the code must contribute to the point of the page that contains it; random stuff running on MDN will be removed by the editor community.

+ +
+

Note: You must use the macro for presenting the live sample's output. MDN's editor will strip out any direct use of the <iframe> element in order to ensure security.

+
+ +

Each {{HTMLElement("pre")}} block containing code for the sample has a class on it that indicates whether it's HTML, CSS, or JavaScript code; these are "brush: html", "brush: css", and "brush: js". These classes must be on the corresponding blocks of code so that the wiki can use them correctly; fortunately, these are added for you automatically when you use the syntax highlighter features in the editor's toolbar.

+ +

The live sample system has lots of options available, and we'll try to break things down to look at them a bit at a time.

+ +

Live sample macros

+ +

There are two macros that you can use to display live samples:

+ + + +

In many cases, you may be able to add the EmbedLiveSample or LiveSampleLink macro to pages with little or no additional work! As long as the sample can be identified by a heading's ID or is in a block with an ID you can use, simply adding the macro should do the job.

+ +

EmbedLiveSample macro

+ +
 \{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
+ +
+
block_ID
+
Required: The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
+
width
+
The width of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default width will be used if you omit this. Note that if you want to use a specific width, you must also specify the height parameter.
+
height
+
The height of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default height will be used if you omit this. Note that if you want to use a specific height, you must also specify the width parameter. If you use only one of them, the default frame size is used.
+
screenshot_URL
+
The URL of a screenshot that shows what the live sample should look like. This is optional, but can be useful for new technologies that may not work in the user's browser, so they can see what the sample would look like if it were supported by their browser. If you include this parameter, the screenshot is shown next to the live sample, with appropriate headings.
+
page_slug
+
The slug of the page containing the sample; this is optional, and if it's not provided, the sample is pulled from the same page on which the macro is used.
+
+ +
    +
+ + + +
 \{{LiveSampleLink(block_ID, link_text)}}
+ +
+
block_ID
+
The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
+
link_text
+
A string to use as the link text.
+
+ +

Using the live sample system

+ +

The sections below describe a few common use cases for the live sample system.

+ +

In all of these cases, to see the results of the live sample, you must click Save Changes in the editor (which takes you out of edit mode). Because of the reflexive, Inception-like nature of live samples, the Preview Changes functionality is not able to display live samples.

+ +

Turning snippets into live samples

+ +

One common use case is to take existing code snippets already shown on MDN and turn them into live samples.

+ +

Prepare the code samples

+ +

The first step is to either add code snippets or ensure that existing ones are ready to be used as live samples, in terms of the content and in terms of their mark-up. The code snippets, taken together, must comprise a complete, runnable example. For example, if the existing snippet shows only CSS, you might need to add a snippet of HTML for the CSS to operate on.

+ +

Each piece of code must be in a {{HTMLElement("pre")}} block, with a separate block for each language, properly marked as to which language it is. Most of the time, this has already been done, but it's always worth double-checking to be sure each piece of code is configured with the correct syntax. Next to the PRE icon in the toolbar is a drop-down menu icon (tooltip: Syntax Highlighter) with the various languages that MDN does syntax highlighting for. Setting the language for the block for syntax highlighting also correlates it with a language for the purposes of the live sample system.

+ +
+

Note: You may have more than one block for each language; they are all concatenated together. This lets you have a chunk of code, followed by an explanation of how it works, then another chunk, and so forth. This makes it even easier to produce tutorials and the like that utilize live samples interspersed with explanatory text.

+
+ +

So make sure the {{HTMLElement("pre")}} blocks for your HTML, CSS, and/or JavaScript code are each configured correctly for that language's syntax highlighting, and you're good to go.

+ +
+

Note: When pasting content into MDN, please be aware that if pasting styled content (including, for example, syntax highlighting in code being copied from another site) that you may be bringing along unwanted and unneeded additional styles or classes. Please be careful not to do this; if necessary, review your edit in source mode to remove these unnecessary styles and classes (or check it before pasting, or use the "Paste as plain text" option instead).

+
+ +

Insert the live sample macro

+ +

Once the code is in place and properly configured to identify each block's language, you need to insert the macro that creates the iframe.

+ +
    +
  1. Click the Insert Live Code Sample iFrame button in the toolbar; it looks like this: . This opens a dialog box for configuring your live sample frame:
    2. +
  2. Under Document, enter the title of the article that contains the sample you wish to embed. By default, it's the article you're currently editing, but you can choose an article elsewhere on MDN, too. This makes it possible to reuse samples on multiple pages if needed. (If you type new text in this field, a menu of partially matching pages appears; select the title of the page you want.)
    3. +
  3. In the Sections in Document menu, select the section in the article that contains the code blocks of the sample you want to embed.
    4. +
  4. Click the OK button to generate and insert the macro call that creates the sample frame for you. The macro call looks something like this:
    + \{{ EmbedLiveSample('Live_sample_demo') }}
    5. +
+ +

Adding a new live sample

+ +

If you're writing a new page, and want to insert code that you want to present as a live sample, even more of the work can be done for you by the editor! 

+ +
    +
  1. Click the Insert Code Sample Template button in the toolbar, which looks like this: . This presents a simple dialog asking you to name your live sample:
    +
    2. +
  2. Enter the title of the sample; this is used as the heading for the sample. Make sure that your title makes sense within the context of the page you're on.
    3. +
  3. Click OK. A new heading with the title you entered is created, with sub-headings and empty code blocks for HTML, CSS, and JavaScript.
    4. +
  4. Delete any headings and code blocks you don't need.
    5. +
  5. Enter the code that makes up your sample in the appropriate code blocks
    6. +
  6. Check conventions
    7. +
+ +

Using the Sample Finder

+ +

As mentioned above, the Sample Finder is activated by clicking the Insert Live Code Sample iFrame icon. Unfortunately the the Sample Finder may produce a macro that is NOT usable without editing. There are two problem areas that should be carefully checked and edited if necessary.

+ +
    +
  1. Document field. This field will search as you type and present a list of documents that match your string. But the list presented will NOT include the sub-page. For example, say you are working on the subpage for Negative under the main page @counter-style. The Sample Finder search will not find Negative but will find the main page @counter-style. When @counter-style is selected the field background turns green. See below for the issue this creates.
    2. +
  2. Sections in Document. The pull-down menu Sections in Document may not show the section that you need. Just pick one, say Examples, and it can be fixed with a simple edit.
    3. +
+ +

Here is what the Sample Finder produced:

+ +
\{{ EmbedLiveSample('Examples', '', '', '', 'Web/CSS/@counter-style') }}
+ +

This macro will not work. The block_ID is Examples and it should be Example in this case (check the source ID for this section to verify which block_ID you need to use. Similarly the page_slug is @counter-style and it should be @counter-style/negative. These corrections can be done directly in the page with Edit active.

+ +

After editing the macro now looks like this:

+ +
\{{ EmbedLiveSample('Example', '', '', '', 'Web/CSS/@counter-style/negative') }}
+ +

This edited macro will work correctly. If the macro is working correctly you will see the Open in CodePen button. A thumbnail of the example should appear above the Open in CodePen button. If the button is there but there isn't a thumbnail, just wait a few minutes. It may take some time for the server to generate it.

+ +

Finding samples that need updating

+ +

When looking for existing samples to update, there are three main kinds of updating you may wish to do:

+ + + +
+

Note: If you find an article that has samples in need of being updated to use the live sample system, please add the tag "NeedsLiveSample" to the page.

+
+ +

Finding samples to turn into live samples

+ +

MDN has lots of older examples that don't yet use the live sample system. Our goal is to update most or all of these to be live samples. This will improve consistency and usability. You will almost certainly find many of these as you use MDN on a daily basis; however, how can you find them if you're specifically looking for them to update? Unfortunately, there's not an easy way to do that. But there are some guidelines you can follow to help track them down:

+ + + +

Live sample demo

+ +

This section is the result of using the live sample template button to create not only the main heading ("Live sample demo"), but also subheadings for our HTML, CSS, and JavaScript content. You're not limited to one block of each; in addition, they don't even need to be in any particular order. Mix and match!

+ +

You may choose to delete any of these you wish; if you don't need any script, just delete that heading and its {{HTMLElement("pre")}} block. You can also delete the heading for a code block ("HTML", "CSS", or "JavaScript"), since these are not used by the live sample macro.

+ +

Now that the template has been inserted, we can put in some code, and even some explanatory text.

+ +

HTML

+ +

This HTML creates a paragraph and some blocks to help us position and style a message.

+ +
<p>A simple example of the live sample system in action.</p>
+<div class="box">
+  <div id="item">Hello world!</div>
+</div>
+
+ +

CSS

+ +

The CSS code styles the box as well as the text inside it.

+ +
.box {
+  width: 200px;
+  height: 100 px;
+  border-radius: 6px;
+  background-color: #ffaabb;
+}
+
+#item {
+  width: 100%;
+  font-weight: bold;
+  text-align: center;
+  font-size: 2em;
+}
+
+ +

JavaScript

+ +

This code is very simple. All it does is attach an event handler to the "Hello world!" text that makes an alert appear when it is clicked.

+ +
var el = document.getElementById('item');
+el.onclick = function() {
+  alert('Owww, stop poking me!');
+}
+
+ +

Result

+ +

Here is the result of running the code blocks above via \{{EmbedLiveSample('Live_sample_demo')}}:

+ +

{{EmbedLiveSample('Live_sample_demo')}}

+ +

Here is a link that results from calling these code blocks via \{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}:

+ +

{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}

+ +

Conventions regarding live samples

+ +
+

Note: This is currently (Feb. 2016) under discussion on the dev-mdc mailing list (see this thread). Any input is welcome. If this note persists after some month (Apr. 2016), please reach the author of the first email in this thread for updating this page.

+
+ +
+
Orders of code blocks
+
When adding a live sample, the code blocks should be sorted so that the first one corresponds to the main language for this sample (if there is one). For example, when adding a live sample for the HTML Reference, the first block should be HTML, when adding a live sample for the CSS Reference, it should be CSS and so on.
+
Naming of headings
+
When there is no ambiguity (e.g. the sample is under a "Examples" section), headings should be straightforward with the sole name of the corresponding language: HTML, CSS, JavaScript, SVG, etc. (see above). Headings like "HTML Content" or "JavaScript Content" should not be used. However if such a short heading makes content unclear, one can use a more thoughtful title.
+
Using a "Result" block
+
After the different code blocks, please use a last "Result" block before using the EmbedLiveSample macro (see above). This way, the semantic of the example is made clearer for both the reader and any tools that would parse the page (e.g. screen reader, web crawler).
+
diff --git a/files/fr/mdn/structures/index.html b/files/fr/mdn/structures/index.html new file mode 100644 index 0000000000..5e605bea37 --- /dev/null +++ b/files/fr/mdn/structures/index.html @@ -0,0 +1,17 @@ +--- +title: Document structures +slug: MDN/Structures +tags: + - Landing + - MDN Meta + - Structures + - TopicStub +translation_of: MDN/Structures +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Tout au long de MDN, il existe diverses structures de document qui sont utilisées à plusieurs reprises, pour fournir une présentation cohérente des informations dans les articles MDN. Voici des articles décrivant ces structures, afin que, en tant qu'auteur MDN, vous puissiez les reconnaître, les appliquer et les modifier selon les besoins pour les documents que vous écrivez, modifiez ou traduisez.

+ +

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/structures/macros/commonly-used_macros/index.html b/files/fr/mdn/structures/macros/commonly-used_macros/index.html new file mode 100644 index 0000000000..39f5a08225 --- /dev/null +++ b/files/fr/mdn/structures/macros/commonly-used_macros/index.html @@ -0,0 +1,224 @@ +--- +title: Commonly-used macros +slug: MDN/Structures/Macros/Commonly-used_macros +translation_of: MDN/Structures/Macros/Commonly-used_macros +--- +
{{MDNSidebar}}
+ +

Cette page présente un grand nombre de macros à usage général créées pour une utilisation avec MDN. Pour avoir des informations sur l'utilisation de ces macros, voir Utilisation des macros et Utiliser les liens macros . Voir les autres macros pour avoir des informations sur les macros qui sont rarement utilisées, ou utilisées dans des contextes spécifiques, ou obsolètes. Il y a aussi une liste complète de toutes les macros MDN.

+ +

Voir aussi le Guide style CSS pour l'utilisation des styles disponibles.

+ +

Linking

+ +

Création d'un lien hypertexte unique

+ +

En général, vous ne devez pas utiliser des macros pour créer des liens arbitraires. Utilisez le Lien dans l'interface de l'éditeur pour créer des liens.

+ + + +

Liens vers des pages avec références

+ +

Il existe différentes macros pour des liens vers des pages dans les zones de référence spécifiques MDN.

+ + + +

Liens vers des bugs et des IRC

+ + + +

Aides à la navigation pour les guides multi-pages

+ +

{{TemplateLink("Previous")}}, {{TemplateLink("Next")}}, and {{TemplateLink("PreviousNext")}} provide navigation controls for articles which are part of sequences. For the single-way templates, the only parameter needed is the wiki location of the previous or next article in the sequence. For {{TemplateLink("PreviousNext")}}, the two parameters needed are the wiki locations of the appropriate articles. The first parameter is for the previous article and the second is for the next article.

+ +

Exemples de code

+ +

Live samples

+ + + +

Fichiers exemples attachés

+ + + +

Génération de sidebar (barre latérale)

+ +

Modèles pour presque toutes les grandes collection de pages. Ils permettent généralement de revenir à la page principale de référence/Guide/tutoriel et de mettre l'article dans la catégorie appropriée.

+ + + +

La mise en forme à usage général

+ +

Inline indicators for API documentation

+ +

{{TemplateLink("optional_inline")}} and {{TemplateLink("ReadOnlyInline")}} are used in API documentation, usually when describing the list of properties of an object or parameters of a function.

+ +

Usage: \{{optional_inline()}} or \{{ReadOnlyInline()}}. Example:

+ +
+
isCustomObject {{ReadOnlyInline()}}
+
Indicates, if true, that the object is a custom one.
+
parameterX {{ optional_inline() }}
+
Blah blah blah...
+
+ +

Status and compatibility indicators

+ +

Inline indicators with no additional parameters

+ +

Non-standard

+ +

{{TemplateLink("non-standard_inline")}} inserts an in-line mark indicating the API has not been standardized and is not on a standards track.

+ +
Syntax
+ +

\{{non-standard_inline}}

+ +
Examples
+ + + +

Experimental

+ +

{{TemplateLink("experimental_inline")}} inserts an in-line mark indicating the API is not widely implemented and may change in the future.

+ +
Syntax
+ +

\{{experimental_inline}}

+ +
Examples
+ + + +

Inline indicators that support specifying the technology

+ +

In these macros the parameter (when specified) should be one of the strings "html", "js", "css", or "gecko", followed by the version number.

+ +

Deprecated

+ +

{{TemplateLink("deprecated_inline")}} inserts an in-line deprecated mark to discourage the use of an API that is officially deprecated. Note: "Deprecated" means that the item should no longer be used, but still functions. If you mean that it no longer works at all, use the term "obsolete."

+ +

Don't use the parameter in any browser-agnostic area (HTML, APIs, JS, CSS, …).

+ +
Syntax
+ +

\{{deprecated_inline}} or \{{deprecated_inline("gecko5")}}

+ +
Examples
+ + + +

Obsolete

+ +

{{TemplateLink("obsolete_inline")}} inserts an in-line obsolete mark to prevent the use of, for example, a function, method or property which is officially obsolete.

+ +

Don't use the parameter in any browser-agnostic area (HTML, APIs, JS, CSS, …).

+ +
Syntax
+ +

\{{obsolete_inline}} or \{{obsolete_inline("js1.8.5")}}

+ +
Examples
+ + + +

Template badges

+ +

These macros are mostly used on the WebAPI page. See {{anch("Creating new badges")}} for information on creating a new badge.

+ +

Page or section header indicators

+ +

These templates have the same semantics as their inline counterparts described above. The templates should be placed directly underneath the main page title (or breadcrumb navigation if available) in the reference page. They can also be used to mark up a section on a page.

+ + + +

Indicating that a feature is available in web workers

+ +

The {{TemplateLink("AvailableInWorkers")}} macro inserts a localised note box indicating that a feature is available in a Web worker context.

+ +

Version information macros

+ +

These macros are used to indicate that content is relevant only to specific versions of a product.

+ + + +

These macros are not shown when the specified version is lower than current gecko release.

+ + + +
    +
+ +

 

+ +
    +
+ +

 

diff --git a/files/fr/mdn/structures/macros/index.html b/files/fr/mdn/structures/macros/index.html new file mode 100644 index 0000000000..19060b70d8 --- /dev/null +++ b/files/fr/mdn/structures/macros/index.html @@ -0,0 +1,40 @@ +--- +title: Macros +slug: MDN/Structures/Macros +translation_of: MDN/Structures/Macros +--- +
{{MDNSidebar}}

La plate-forme Kuma sur laquelle MDN travail, fournit un système de macro, KumaScript, ce qui permet de faire une grande variété de choses automatiquement. Cet article fournit des informations sur la façon d'invoquer les macros MDN dans les articles.

+ +

Le Guide KumaScript offre un regard en profondeur sur la façon d'utiliser des macros MDN, cette section est plus qu'un bref aperçu. Si vous avez déjà lu la section ci-dessus sur {{SectionOnPage ("/docs/fr/projet:MDN/Contribuer/Editor_guide/Links", "Utiliser les liens macros")}}, vous êtes un peu familiers avec le concept.

+ +

Comment les macros sont-elle mises en œuvre

+ +

Macros sur MDN sont mis en œuvre en utilisant le serveur exécuté JavaScript code, interprété à l'aide de Node.js. En plus de cela, nous avons un certain nombre de bibliothèques, que nous avons mis en place pour fournir des services et des fonctionnalités orientées wiki, les macros interagissent avec la plate-forme wiki et avec son contenu. Si vous voulez en apprendre davantage, consultez le guide KumaScript; le KumaScript reference fournit des détails sur les bibliothèques et autres API KumaScript que nous avons mis en œuvre.

+ +

Utiliser une macro dans le contenu

+ +

Pour réellement utiliser une macro, vous placez simplement l'appel à la macro dans une paire de doubles acolades, avec ses paramètres, le cas échéant, entre parenthèses:

+ +
\{{macroname(parameter-list)}}
+ +

Quelques notes sur les appels de macro:

+ + + +

Les macros sont mis en cache; pour tout ensemble de valeurs d'entrée (les paramètres et les valeurs environnementales telles que l'URL pour laquelle la macro a été exécutée), les résultats sont stockés et réutilisés. Cela signifie que la macro est que effectivement parcourue que lorsque les entrées changent.

+ +
+

Remarque:. Vous pouvez forcer toutes les macros d'une page à être réévalué avec un shift-reload.

+
+ +

Les macros peuvent être aussi simple que d'insérer un plus grand bloc de texte ou d'échange dans le contenu d'une autre partie du MDN, ou aussi complexe que la construction de tout un index du contenu en cherchant dans des parties du site, coiffer la sortie, et en ajoutant des liens.

+ +

Vous pouvez lire sur nos macros les plus couramment utilisés sur le couramment utilisés; aussi, il y a un la liste complète de toutes les macros ici. La plupart des macros ont intégré dans la documentation eux, comme des commentaires en haut.

+ +

{{EditorGuideQuicklinks}}

diff --git "a/files/fr/mdn/structures/tables_de_compatibilit\303\251/index.html" "b/files/fr/mdn/structures/tables_de_compatibilit\303\251/index.html" new file mode 100644 index 0000000000..cb334e51c4 --- /dev/null +++ "b/files/fr/mdn/structures/tables_de_compatibilit\303\251/index.html" @@ -0,0 +1,503 @@ +--- +title: Tables de compatibilité +slug: MDN/Structures/Tables_de_compatibilité +tags: + - Compatibilité + - Documentation + - Guide + - MDN + - Navigateurs +translation_of: MDN/Structures/Compatibility_tables +--- +
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

MDN a un format standard pour les tables de compatibilité de notre documentation du web ouvert ; c'est-à-dire la documentation de technologies comme le DOM, HTML, CSS, JavaScript, SVG etc. partagées par tous les navigateurs. Cet article explique comment utiliser nos fonctionnalités pour ajouter des données de compatibilité aux pages MDN.

+ +
+

Important : La façon dont les données sont générées a changé. Historiquement, nos tables ont été insérées sur la page et les données ont été renseignées manuellement. Ceci est inefficace, rend la maintenance difficile et rend les données inflexibles. Par conséquent, nous migrons les données de notre navigateur pour les stocker dans un référentiel de données (voir https://github.com/mdn/browser-compat-data) et générer les tables par programme.
+
+ Dans ce guide, nous documentons la nouvelle façon d'ajouter des données aux tables de compatibilité pour MDN, mais nous avons conservé la documentation à l'ancienne, car vous pourrez voir des tables manuelles sur MDN pendant un moment. Si vous avez besoin de la documentation ancienne, voyez notre article Anciennes tables de compatibilité.

+
+ +
+

Note : Si vous avez besoin d'aide sur les étapes de ce guide, n'hésitez pas à nous contacter sur le forum de discussion MDN (en).

+
+ +

Comment accéder au dépôt de données

+ +

Les données sont stockées dans un dépôt de GitHub — voir https://github.com/mdn/browser-compat-data. Pour y accéder, vous devez obtenir un compte GitHub, réaliser une branche du browser-compat-data sur votre propre compte, puis cloner votre branche sur votre machine locale.

+ +

Choisir une fonctionnalité pour y ajouter des données

+ +

Tout d'abord, cherchez une fonctionnalité pour laquelle vous souhaitez ajouter des données de navigateur. Cela peut être un élément HTML, une propriété CSS, une fonctionnalité du langage JS ou une interface d'API JS, par exemple. Nous aimerions vous encourager à travailler sur les fonctionnalités de l'API, car nous avons déjà des personnes travaillant sur HTML, JS et CSS. Vous pouvez trouver le statut des fonctionnalités qui ont besoin de leurs données en ajoutant au dépôt sur notre tableur Browser Compat Data migration (migration des données des tables de compatibilité des navigateurs).

+ +

Le processus d'utilisation est le suivant :

+ +
    +
  1. Allez-y et choisissez une fonctionnalité qui n'est pas déjà travaillée ou complète. Inscrivez votre nom dans la colonne "Who" (qui), de préférence avec votre nom d'utilisateur MDN afin que nous puissions trouver votre adresse e-mail et vous contacter si nécessaire.
    2. +
  2. Si la fonctionnalité sur laquelle vous souhaitez travailler n'est pas déjà répertoriée dans la feuille de calcul, ajoutez-y des lignes à un emplacement approprié, en copiant le format qui s'y trouve déjà. Vous devez également utiliser la même granularité (par exemple, par élément pour HTML, par propriété ou sélecteur pour CSS, par objet pour JS, par interface pour API).
    3. +
  3. Une fois que vous avez commencé à ajouter des données, mettez le statut "In progres" (En cours).
    4. +
  4. Une fois que vous avez ajouté les données et soumis une demande d'extraction au dépôt principal, attribuez le statut "PR done".
    5. +
  5. Au fur et à mesure que vos données sont fusionnées au rapport, ajoutées au paquet npm, mettez à jour le statut si nécessaire.
    6. +
  6. Une fois que vous avez mis à jour les pages de documentation pour votre fonctionnalité afin d'utiliser la nouvelle macro pour générer dynamiquement la table de données appropriée sur chaque page, définissez l'état sur "Article mis à jour". À ce stade, vous avez terminé.
    7. +
+ +

Préparation à l'ajout de données

+ +

Avant d'ajouter de nouvelles données, vous devez vous assurer que votre branche est à jour avec le dépôt principal (le même contenu), créer une nouvelle branche dans votre embranchement pour contenir vos ajouts, puis récupérer cette branche dans votre clone local pour pouvoir commencer à y travailler :

+ +

Regardons un moyen simple de nous assurer que votre fourche est à jour :

+ +

Ajout d'un "remote" au dépôt principal navigateur-compat-données

+ +

Accédez à votre clone local de la branche dans votre terminal / ligne de commande, et ajoutez un"remote" pointant vers le dépôt principal (en amont) comme ceci (vous n'avez besoin de le faire qu'une seule fois):

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

Si vous n'êtes pas sûr d'y être parvenu, vous pouvez vérifier quels "remotes" votre dépôt utilise.

+ +
git remote -v
+ +

Mise à jour de votre branche avec le contenu du "remote"

+ +

Maintenant, chaque fois que vous voulez mettre à jour votre branche, vous pouvez le faire en :

+ +
    +
  1. +

    Vous assurant que vous êtes dans la branche maîtresse :

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

    Allant chercher le contenu du dépôt à jour avec la commande suivante :

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

    Rebasant le contenu de votre branche maîtresse avec le contenu du dépôt principal :

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

    poussant ces mises à jour de votre branche distante en utilisant ce :

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

Création d'une nouvelle branche pour y travailler

+ +

Ensuite, allez sur votre fourche distante (elle doit être à https://github.com/your-username/browser-compat-data) et créer une nouvelle branche pour stocker vos modifications pour cet ajout de données. Ceci peut être fait en:

+ +
    +
  1. Cliquant sur le bouton "Branch: Master".
    2. +
  2. Saisissant le nom de votre nouvelle branche dans le champ texte "Find or create a branch...".
    3. +
  3. Cliquant sur le bouton "Create branch name-of-branch from Master" qui vient d'être généré.
    4. +
+ +

Par exemple, si vous vouliez ajouter des données pour l'API WebVR, vous devriez créer une branche nommée "webvr".

+ +

Aller sur la nouvelle branche

+ +

A ce stade, retournez dans votre terminal / ligne de commande, et mettez à jour la copie de votre fourche locale pour inclure votre nouvelle branche en utilisant la commande suivante:

+ +
git pull
+ +

Maintenant allez sur votre nouvelle branche en utilisant:

+ +
git checkout -b name-of-branch
+ +

Vous devriez maintenant être prêt à ajouter vos données!

+ +

Ajouter les données

+ +

Pour ajouter les données, vous devez créer un ou des nouveaux fichiers pour y stocker les données de compatibilité. Les fichiers que vous devez créer diffèrent, selon la technologie sur laquelle vous travaillez:

+ + + +
+

Note: Vous remarquerez que le dépôt contient aussi des données pour les Extensions de navigateurs et pour HTTP. Ces ensembles de données sont esssentiellement finis en l'état, mais il faudra peut-être ajouter d'autres fonctionnalités à l'avenir.

+
+ +

Chaque fichier que vous créez doit suivre le modèle défini dans le schéma contenu dans notre dépôt; vous pouvez voir la description détaillée du schema ici.

+ +

Structure basique des données de compatibilité

+ +

Prenons un exemple. Les fichiers JSON de propriété CSS ont par exemple besoin de la structure de base suivante:

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

Vous avez l'objet css, à l'intérieur duquel vous avez l'objet properties. A l'intérieur de l'objet properties, vous avez besoin d'un membre pour chacunes des fonctionnalités  dont vous voulez définir les données. Chacun de ces membres a un membre __compat, à l'intérieur duquel les données vont.

+ +

Les données ci-dessus se trouvent dans le fichier border-width.json — comparez les à la  table de support de border-width disponible sur MDN.

+ +

D'autres types de fonctionnalités fonctionnent sur le même principe, mais avec des noms d'objets différents:

+ + + +
+

Dans les pages HTML, CSS, et JS, vous n'avez normalement besoin que d'une seule fonctionnalité. Les interfaces d'API fonctionnent légèrement différement — elles ont toujours de multiples sous caractéristiques (voir {{anch("Sub-features")}}, ci-dessous).

+ +

Structure de base à l'intérieur d'une fonctionnalité

+ +

Dans un membre __compat, vous devez inclure les membres suivants:

+ + + +

Les noms des membres pour le navigateur sont définis dans le schéma (voir Browser identifiers). Vous devez utiliser la liste complète des identifiants actuellement définis. Si vous souhaitez ajouter un navigateur, parlez-nous en d'abord, car cela pourrait avoir un impact important et ne devrait pas être fait sans une réflexion approfondie.

+ +

Dans un fichier de base de compatibilité de navigateur, vous n'avez qu'à inclure "version_added" dans les membres de l'identifiant de navigateur (nous reviendrons plus tard sur {{anch("Advanced cases")}}). Les différentes valeurs que vous pouvez inclure sont les suivantes:

+ + + +

A l'intérieur du membre status, vous inclurez trois sous-membres:

+ + + +

Les données pour la propriété border-width (voir aussi border-width.json) sont présentées ci-dessous à titre d'exemple:

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

Ajouter une description

+ +

Il y a un quatrième membre, optionnel, qui peut être placé à l'intérieur du membre __compat — description. Ceci peut être utilisé pour inclure une description, compréhensible par les humains, de cette fonctionnalité. Vous ne devez l'inclure que s'il est difficile de voir de quoi il s'agit en ne regardant que les données. Par exemple, il peut ne pas être évident qu'il s'agit d'un constructeur en ne regardant que la structure des données, vous pouvez donc ajouter une description comme:

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

Sub-features

+ +

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

+ +

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

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

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

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

See VRDisplay.json for a full example.

+
+ +

Adding data: Advanced cases

+ +

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

+ +

Including a footnote

+ +

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

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

Including a vendor prefix

+ +

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

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

Including browser preferences or flags

+ +

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

+ +

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

+ + + +

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

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

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

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

Including a version where support was removed

+ +

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

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

Including multiple support points for the same browser entry

+ +

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

+ +

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

+ +

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

+ +

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

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

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

+
+ +

Including an alternative name

+ +

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

+ +

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

+ +
+

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

+
+ +

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

+ + + +

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

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

Pushing a change back to the main repo

+ +

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

+ + + +

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

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

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

+ +

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

+ +

Inserting the data into MDN pages

+ +

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

+ +

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

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

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

+ +

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

+ +
+ + +

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

+ +
+

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

+
diff --git a/files/fr/mdn/tools/index.html b/files/fr/mdn/tools/index.html new file mode 100644 index 0000000000..340603eece --- /dev/null +++ b/files/fr/mdn/tools/index.html @@ -0,0 +1,16 @@ +--- +title: MDN tools +slug: MDN/Tools +tags: + - Landing + - MDN Meta + - TopicStub +translation_of: MDN/Tools +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

MDN offre un certain nombre de fonctionnalités qui facilitent le suivi des progrès, la gestion du contenu et le suivi des dernières modifications apportées au site.

+ +

{{LandingPageListSubpages}}

diff --git a/files/fr/mdn/tools/kumascript/index.html b/files/fr/mdn/tools/kumascript/index.html new file mode 100644 index 0000000000..9ded41a11a --- /dev/null +++ b/files/fr/mdn/tools/kumascript/index.html @@ -0,0 +1,499 @@ +--- +title: KumaScript +slug: MDN/Tools/KumaScript +tags: + - Guide + - Kuma + - KumaScript + - MDN + - MDN Meta +translation_of: MDN/Tools/KumaScript +--- +
{{MDNSidebar}}
+ +
+ +

Sur la plate-forme Kuma qui propulse MDN, le système de modèles pour automatiser certains aspects du contenu sur le wiki est appelé KumaScript. KumaScript repose sur du JavaScript côté serveur implanté à l'aide de Node.js. Cet article vous fournit des informations basiques sur l'utilisation de KumaScript.

+ +

Pour un aperçu détaillé et des questions et réponses sur KumaScript, visitez la discussion Fireside KumaScript de l'équipe de développement de MDN. KumaScript a remplacé DekiScript, qui était le langage modèle pour MindTouch, la précédente plate-forme utilisée par MDN.

+ +

Qu'est KumaScript ?

+ + + +

Ce que KumaScript n'est pas

+ + + +

Les bases

+ +

KumaScript fonctionne en permettant aux utilisateurs MDN de confiance d'écrire des modèles JavaScript embarqués. Ces modèles peuvent être invoqués dans le contenu du document par tout auteur MDN via l'usage de macros.

+ +

Un script en KumaScript est un modèle, et chaque modèle est un fichier du dépôt Github. Un modèle ressemble à ceci :

+ +
<% for (var i = 0; i < $0; i++) { %>
+Hello #<%= i %>
+<% } %>
+ +

Invoquer un modèle se fait avec un macro, pouvant être utilisé à tout endroit dans toute page wiki. Un macro ressemble à ceci :

+ +
\{{ hello("3") }}
+ +

La sortie du macro ressemble à :

+ +
Hello #0
+Hello #1
+Hello #2
+ +

Syntaxe des macro

+ +

Les modèles KumaScript sont invoqués dans le contenu d'un document avec des macros comme ceci :

+ +
\{{ templateName("arg0", "arg1", ..., "argN") }}
+
+ +

La syntaxe des macros consiste en quatre règles :

+ + + +

Utiliser JSON comme paramètre de macro

+ +

En tant que fonctionnalité semi-expérimentale (il n'est pas garantie qu'elle fonctionne), vous pouvez fournir un objet JSON pour le premier paramètre uniquement, par exemple :

+ +
\\{{ templateName({ "Alpha":"one", "Beta":["a","b","c"], "Foo":"http:\/\/mozilla.org\/" }) }}
+
+ +

Les données de ce macro sont disponibles dans le code du modèle en tant qu'objet à l'argument $0 (par exemple $0.Alpha, $0.Beta, $0.Foo). Celà vous permet aussi d'exprimer des structures de données complexes dans les paramètres des macros qu'il serait difficile voire impossible d'exprimer comme une simple liste de paramètres.

+ +

Notee que ce style de paramètre est très strict — il doit correspondre exactement à la syntaxe JSON, qui a quelques contraintes sur l'échappement des caractères qu'il est aisé d'oublier (par exemple que toutes les barres obliques culbutées doivent être échapées). Si vous avez un doute, essayer de faire passer votre JSON dans un validateur.

+ +

Comment écrire "\\{{" dans du texte

+ +

Bien que la séquence de caractères "\\{{" soit utilisée pour démarrer un macro, elle peut causer des problèmes si vous voulez seulement écrire "\\{{" et "}}" sur une page. Celà produira alors probablement des messages DocumentParsingError.

+ +

Dans ce cas, vous pouvez échapper la barre oblique culbutée avec une seconde barre, tel que : \\\{{

+ +

Syntaxe des modèles

+ +

Each KumaScript template is kept in a separate wiki page. Creating and editing these pages requires an elevated privilege, which MDN admins can grant to trusted editors.

+ +

KumaScript templates are processed by an embedded JavaScript template engine with a few simple rules:

+ + + +

Tips

+ +

Dates and times

+ +

It's important to note that the standard JavaScript {{jsxref("Date")}} constructor is overridden by the KumaScript Date interface. You can create a JavaScript Date by calling the KumaScript date.now() or date.parse() function.

+ +

Fonctionnalités avancées

+ +

Beyond the basics, the KumaScript system offers some advanced features.

+ +

Variables d'environnement

+ +

When the wiki makes a call to the KumaScript service, it passes along some context on the current document that KumaScript makes available to templates as variables:

+ +
+
env.path
+
The path to the current wiki document
+
env.url
+
The full URL to the current wiki document
+
env.id
+
A short, unique ID for the current wiki document
+
env.files
+
An array of the files attached to the current wiki document; each object in the array is as described under {{ anch("File objects") }} below
+
env.review_tags
+
An array of the review tags on the article ("technical", "editorial", etc.)
+
env.locale
+
The locale of the current wiki document
+
env.title
+
The title of the current wiki document
+
env.slug
+
The URL slug of the current wiki document
+
env.tags
+
An array list of tag names for the current wiki document
+
env.modified
+
Last modified timestamp for the current wiki document
+
env.cache_control
+
Cache-Control header sent in the request for the current wiki document, useful in deciding whether to invalidate caches
+
+ +

File objects

+ +

Each file object has the following fields:

+ +
+
title
+
The attachment's title
+
description
+
A textual description of the current revision of the file
+
filename
+
The file's name
+
size
+
The size of the file in bytes
+
author
+
The username of the person who uploaded the file
+
mime
+
The MIME type of the file
+
url
+
The URL at which the file can be found
+
+ +

Working with tag lists

+ +

The env.tags and env.review_tags variables return arrays of tags. You can work with these in many ways, of course, but here are a couple of suggestions.

+ +
Looking to see if a specific tag is set
+ +

You can look to see if a specific tag exists on a page like this:

+ +
if (env.tags.indexOf("tag") != −1) {
+  // The page has the tag "tag"
+}
+
+ +
Iterating over all the tags on a page
+ +

You can also iterate over all the tags on a page, like this:

+ +
env.tag.forEach(function(tag) {
+  // do whatever you need to do, such as:
+  if (tag.indexOf("a") == 0) {
+    // this tag starts with "a" - woohoo!
+  }
+});
+ +

APIs and Modules

+ +

KumaScript offers some built-in utility APIs, as well as the ability to define new APIs in modules editable as wiki documents.

+ +

Built-in methods

+ +

This manually-maintained documentation is likely to fall out of date with the code. With that in mind, you can always check out the latest state of built-in APIs in the KumaScript source. But here is a selection of useful methods exposed to templates:

+ +
+
md5(string)
+
Returns an MD5 hex digest of the given string.
+
template("name", ["arg0", "arg1", ..., "argN"])
+
Executes and returns the result of the named template with the given list of parameters.
+
Example: <%- template("warning", ["foo", "bar", "baz"]) %>.
+
Example using the domxref macro: <%- template("domxref", ["Event.bubbles", "bubbles"]) %>.
+
This is a JavaScript function. So, if one of the parameters is an arg variable like $2, do not put it in quotes. Like this: <%- template("warning", [$1, $2, "baz"]) %>. If you need to call another template from within a block of code, do not use <% ... %>. Example: myvar = "<li>" + template("LXRSearch", ["ident", "i", $1]) + "</li>";
+
require(name)
+
Loads another template as a module; any output is ignored. Anything assigned to module.exports in the template is returned.
+
Used in templates like so: <% var my_module = require('MyModule'); %>.
+
cacheFn(key, timeout, function_to_cache)
+
Using the given key and cache entry lifetime, cache the results of the given function. Honors the value of env.cache_control to invalidate cache on no-cache, which can be sent by a logged-in user hitting shift-refresh.
+
request
+
Access to mikeal/request, a library for making HTTP requests. Using this module in KumaScript templates is not yet very friendly, so you may want to wrap usage in module APIs that simplify things.
+
log.debug(string)
+
Outputs a debug message into the script log on the page (i.e. the big red box that usually displays errors).
+
+ +

Built-in API modules

+ +

There's only one API built in at the moment, in the kuma namespace. You can see the most up to date list of methods under kuma from the KumaScript source code, but here are a few:

+ +
+
kuma.inspect(object)
+
Renders any JS object as a string, handy for use with log.debug(). See also: node.js util.inspect().
+
+ +
+
kuma.htmlEscape(string)
+
Escapes the characters &, <, >, " to &amp, &lt;, &gt;, &quot;, respectively.
+
kuma.url
+
See also: node.js url module.
+
kuma.fetchFeed(url)
+
Fetch an RSS feed and parse it into a JS object. See also: Template:InsertFeedLinkList
+
+ +

Creating modules

+ +

Using the built-in require() method, you can load a template as a module to share common variables and methods between templates. A module can be defined in a template like this:

+ +
<%
+module.exports = {
+    add: function (a, b) {
+        return a + b;
+    }
+}
+%>
+
+ +

Assuming this template is saved as /en-US/docs/Template:MathLib, you can use it in another template like so:

+ +
<%
+var math_lib = require("MathLib");
+%>
+The result of 2 + 2 = <%= math_lib.add(2, 2) %>
+
+ +

And, the output of this template will be:

+ +
The result of 2 + 2 = 4
+
+ +

Auto-loaded modules

+ +

There are a set of modules editable as wiki templates that are automatically loaded and made available to every template. This set is defined in the configuration file for the KumaScript service - any changes to this requires an IT bug to edit configuration and a restart of the service.

+ +

For the most part, these attempt to provide stand-ins for legacy DekiScript features to ease template migration. But, going forward, these can be used to share common variables and methods between templates:

+ + + +

Note: You might notice that the DekiScript modules use a built-in method named buildAPI(), like so:

+ +
<% module.exports = buildAPI({
+    StartsWith: function (str, sub_str) {
+        return (''+str).indexOf(sub_str) === 0;
+    }
+}); %>
+
+ +

The reason for this is because DekiScript is case-insensitive when it comes to references to API methods, whereas JavaScript is strict about uppercase and lowercase in references. So, buildAPI() is a hack to try to cover common case variations in DekiScript calls found in legacy templates.

+ +
+

With that in mind, please do not use buildAPI() in new modules.

+
+ +

Tips and caveats

+ +

Debugging

+ +

A useful tip when debugging. You can use the log.debug() method to output text to the scripting messages area at the top of the page that's running your template. Note that you need to be really sure to remove these when you're done debugging, as they're visible to all users! To use it, just do something like this:

+ +
<%- log.debug("Some text goes here"); %>
+
+ +

You can, of course, create more complex output using script code if it's helpful.

+ +

Caching

+ +

KumaScript templates are heavily cached to improve performance. For the most part, this works great to serve up content that doesn't change very often. But, as a logged-in user, you have two options to force a page to be regenerated, in case you notice issues with scripting:

+ + + +

Using search keywords to open template pages

+ +

When using templates, it's common to open the template's code in a browser window to review the comments at the top, which are used to document the template, its parameters, and how to use it properly. To quickly access templates, you can create a Firefox search keyword, which gives you a shortcut you can type in the URL box to get to a template more easily.

+ +

To create a search keyword, open the bookmarks window by choosing "Show all bookmarks" in the Bookmarks menu, or by pressing Control-Shift-B (Command-Shift-B on Mac). Then from the utility ("Gear") menu in the Library window that appears, choose "New Bookmark...".

+ +

This causes the bookmark editing dialog to appear. Fill that out as follows:

+ +
+
Name
+
A suitable name for your search keyword; "Open MDN Template" is a good one.
+
Location
+
https://developer.mozilla.org/en-US/docs/Template:%s
+
Tags {{optional_inline}}
+
A list of tags used to organize your bookmarks; these are entirely optional and what (if any) tags you use is up to you.
+
Keyword
+
The shortcut text you wish to use to access the template. Ideally, this should be something short and quick to type, such as simply "t" or "mdnt".
+
Description {{optional_inline}}
+
A suitable description explaining what the search keyword does.
+
+ +

The resulting dialog looks something like this:

+ +

The bookmark editor box showing how a search keyword to open templates looks.

+ +

Then click the "Add" button to save your new search keyword. From then on, typing your keyword, then a space, then the name of a macro will open that macro in your current tab. So if you used "t" as the keyword, typing t ListSubpages will show you the page at {{TemplateLink("ListSubpages")}}.

+ +

Cookbook

+ +

This section will list examples of common patterns for templates used on MDN, including samples of legacy DekiScript templates and their new KumaScript equivalents.

+ +

Force templates used on a page to be reloaded

+ +

It bears repeating: To force templates used on a page to be reloaded after editing, hit Shift-Reload. Just using Reload by itself will cause the page contents to be regenerated, but using cached templates and included content. A Shift-Reload is necessary to invalidate caches beyond just the content of the page itself.

+ +

Recovering from "Unknown Error"

+ +

Sometimes, you'll see a scripting message like this when you load a page:

+ +
Kumascript service failed unexpectedly: <class 'httplib.BadStatusLine'>
+ +

This is probably a temporary failure of the KumaScript service. If you Refresh the page, the error may disappear. If that doesn't work, try a Shift-Refresh. If, after a few tries, the error persists - file an IT bug for Mozilla Developer Network to ask for an investigation.

+ +

Broken wiki.languages() macros

+ +

On some pages, you'll see a scripting error like this:

+ +
Syntax error at line 436, column 461: Expected valid JSON object as the parameter of the preceding macro but...
+
+ +

If you edit the page, you'll probably see a macro like this at the bottom of the page:

+ +
\{{ wiki.languages({ "zh-tw": "zh_tw/Core_JavaScript_1.5_教學/JavaScript_概要", ... }) }}
+
+ +

To fix the problem, just delete the macro. Or, replace the curly braces on either side with HTML comments <!-- --> to preserve the information, like so:

+ +
<!-- wiki.languages({ "zh-tw": "zh_tw/Core_JavaScript_1.5_教學/JavaScript_概要", ... }) -->
+
+ +

Because Kuma supports localization differently, these macros aren't actually needed any more. But, they've been left intact in case we need to revisit the relationships between localized pages. Unfortunately, it seems like migration has failed to convert some of them properly.

+ +

Finding the Current Page's Language

+ +

In KumaScript, the locale of the current document is exposed as an environment variable:

+ +
var lang = env.locale;
+
+ +

The env.locale variable should be reliable and defined for every document.

+ +

Reading the contents of a page attachment

+ +

You can read the contents of an attached file by using the mdn.getFileContent() function, like this:

+ +
<%
+  var contents = mdn.getFileContent(fileUrl);
+  ... do stuff with the contents ...
+%>
+
+ +

or

+ +
<%-mdn.getFileContent(fileObject)%>
+
+ +

In other words, you may specify either the URL of the file to read or as a file object. The file objects for a page can be accessed through the array env.files. So, for example, to embed the contents of the first file attached to the article, you can do this:

+ +
<%-mdn.getFileContent(env.files[0])%>
+
+ +
Note: You probably don't want to try to embed the contents of a non-text file this way, as the raw contents would be injected as text. This is meant to let you access the contents of text attachments.
+ +

If the file isn't found, an empty string is returned. There is currently no way to tell the difference between an empty file and a nonexistent one. But if you're putting empty files on the wiki, you're doing it wrong.

+ +

Localizing template content

+ +

Templates cannot be translated like other wiki pages. KumaScript only looks for templates in the en-US locale (i.e., /en-US/docs/Template:{name}), and does not look for templates that have been translated to another locale (i.e., /fr/docs/Template:{name}).

+ +

So the main way to output content tailored to the current document locale is to pivot on the value of env.locale. There are many ways to do this, but a few patterns are common in the conversion of legacy DekiScript templates:

+ +

If/else blocks in KumaScript

+ +

The KumaScript equivalent of this can be achieved with simple if/else blocks, like so:

+ +
<% if ("fr" == env.locale) { %>
+<%- template("CSSRef") %> « <a title="Référence_CSS/Extensions_Mozilla" href="/fr/docs/Référence_CSS/Extensions_Mozilla">Référence CSS:Extensions Mozilla</a>
+<% } else if ("ja" == env.locale) { %>
+<%- template("CSSRef") %> « <a title="CSS_Reference/Mozilla_Extensions" href="/ja/docs/CSS_Reference/Mozilla_Extensions">CSS リファレンス:Mozilla 拡張仕様</a>
+<% } else if ("pl" == env.locale) { %>
+<%- template("CSSRef") %> « <a title="Dokumentacja_CSS/Rozszerzenia_Mozilli" href="/pl/docs/Dokumentacja_CSS/Rozszerzenia_Mozilli">Dokumentacja CSS:Rozszerzenia Mozilli</a>
+<% } else if ("de" == env.locale) { %>
+<%- template("CSSRef") %> « <a title="CSS_Referenz/Mozilla_CSS_Erweiterungen" href="/de/docs/CSS_Referenz/Mozilla_CSS_Erweiterungen">CSS Referenz: Mozilla Erweiterungen</a>
+<% } else { %>
+<%- template("CSSRef") %> « <a title="CSS_Reference/Mozilla_Extensions" href="/en-US/docs/CSS_Reference/Mozilla_Extensions">CSS Reference:Mozilla Extensions</a>
+<% } %>
+
+ +

Depending on what text editor is your favorite, you may be able to copy & paste from the browser-based editor and attack this pattern with a series of search/replace regexes to get you most of the way there.

+ +

My favorite editor is MacVim, and a series of regexes like this does the bulk of the work with just a little manual clean up following:

+ +
%s#<span#^M<span#g
+%s#<span lang="\(.*\)" .*>#<% } else if ("\1" == env.locale) { %>#g
+%s#<span class="script">template.Cssxref(#<%- template("Cssxref", [#
+%s#)</span> </span>#]) %>
+
+ +

Your mileage may vary, and patterns change slightly from template to template. That's why the migration script was unable to just handle this automatically, after all.

+ +

String variables and switch

+ +

Rather than switch between full chunks of markup, you can define a set of strings, switch them based on locale, and then use them to fill in placeholders in a single chunk of markup:

+ +
<%
+var s_title = 'Firefox for Developers';
+switch (env.locale) {
+    case 'de':
+        s_title = "Firefox für Entwickler";
+        break;
+    case 'fr':
+        s_title = "Firefox pour les développeurs";
+        break;
+    case 'es':
+        s_title = "Firefox para desarrolladores";
+        break;
+};
+%>
+<span class="title"><%= s_title %></span>
+
+ +

Use mdn.localString()

+ +

A recent addition to the Template:MDN:Common module is mdn.localString(), used like this:

+ +
<%
+var s_title = mdn.localString({
+  "en-US": "Firefox for Developers",
+  "de": "Firefox für Entwickler",
+  "es": "Firefox para desarrolladores"
+});
+%>
+<span class="title"><%= s_title %></span>
+
+ +

This is more concise than the switch statement, and may be a better choice where a single string is concerned. However, if many strings need to be translated (e.g., as in CSSRef), a switch statement might help keep all the strings grouped by locale and more easily translated that way.

+ +

When the object does not have the appropriate locale, the value of "en-US" is used as the initial value.

+ +

See also

+ + diff --git a/files/fr/mdn/tools/template_editing/index.html b/files/fr/mdn/tools/template_editing/index.html new file mode 100644 index 0000000000..3f56b7d1f9 --- /dev/null +++ b/files/fr/mdn/tools/template_editing/index.html @@ -0,0 +1,15 @@ +--- +title: Template editing +slug: MDN/Tools/Template_editing +tags: + - Guide + - MDN + - MDN Meta + - Outils +translation_of: MDN/Tools/Template_editing +--- +
{{MDNSidebar}}
+ +

Sur MDN, les modèles écrits en KumaScript sont utilisées pour automatiser la génération de contenu et la personnalisation au sein des pages. Chaque modèle est un fichier séparé dans le dossier des macros du dépôt Github de KumaScript.

+ +

Toute personne éditant les pages wiki de MDN peut invoquer des modèles via des macros sur les articles MDN. Chacun peut créer et éditer des modèles via le dépôt Github de KumaScript en utilisant les pratiques normées du logiciel libre (copier le dépôt, créer une branche, faire ses changements, et soumettre une requête de publication à la relecture).Notez que soumettre une requête de publication est courrament le seul moyen de mettre à jour les chaînes traduites dans les modèles qui les contiennent.

diff --git a/files/fr/mdn/user_guide/index.html b/files/fr/mdn/user_guide/index.html new file mode 100644 index 0000000000..78310bc1fb --- /dev/null +++ b/files/fr/mdn/user_guide/index.html @@ -0,0 +1,13 @@ +--- +title: Guide de l'utilisateur MDN +slug: MDN/User_guide +tags: + - Documentation + - Démarrer + - MDN + - Projet MDC +translation_of: MDN/Tools +--- +
{{MDNSidebar}}

Le site Mozilla Developper Network est un système avancé pour trouver, lire et contribuer à la documentation ainsi qu'au code pour les développeurs Web (mais aussi pour les développeurs Firefox et Firefox OS). Le guide de l'utilisateur MDS regorge d'articles détaillant comment utiliser le site MDS pour trouver la documentation dont vous avez besoin et si vous le désirez, comment aider à rendre les outils encore meilleurs et complets.

+ +

{{LandingPageListSubpages}}

diff --git "a/files/fr/mdn/user_guide/r\303\251daction/index.html" "b/files/fr/mdn/user_guide/r\303\251daction/index.html" new file mode 100644 index 0000000000..a9dcd7f7cf --- /dev/null +++ "b/files/fr/mdn/user_guide/r\303\251daction/index.html" @@ -0,0 +1,61 @@ +--- +title: Rédaction de contenu +slug: MDN/User_guide/Rédaction +tags: + - MDN + - Projet MDC +translation_of: Archive/Meta_docs/Writing_content +--- +
{{MDNSidebar}}

Il y a toujours des choses qui peuvent être ajoutées ou mises à jour sur le MDN. Que ce soit une toute nouvelle documentation pour une nouvelle API brillante ou la révision d'une ancienne API qui a changé subtilement, vous trouverez beaucoup de possibilités pour aider.

+ +

Modifier une page existante

+ +

Si vous avez trouvé une page que vous souhaitez réviser, cliquez simplement sur le bouton « Modifier » dans le coin supérieur droit. Cela ouvrira l'éditeur WYSIWYG pour travailler sur le contenu de la page. Consultez le guide de l'éditeur MDN pour plus de détails sur la façon de travailler avec l'éditeur, ainsi que la façon de travailler avec le système macro que nous utilisons pour aider à automatiser la construction et la mise en forme du contenu.

+ +

Il y a de nombreuses raisons qui peuvent vous pousser à modifier une page existante :

+ + + +

Ajouter une nouvelle page

+ +

Voici le grand défi ! Ajouter une nouvelle page de MDN permet de construire le Web que vous aimez tant et que vous voulez étreindre. Il existe plusieurs raisons évidentes pour créer une nouvelle page, comme documenter une API qui n'est pas encore documentée ou pour ajouter un nouveau tutoriel ou un guide sur un sujet.

+ +

Il y a plusieurs manières d'aller sur la création d'une nouvelle page sur MDN, une fois que vous êtes connecté:

+ +
+
Cliquez sur le lien "page manquante"
+
Lorsque vous naviguez sur MDN, vous aurez l'occasion de trouver des liens vers des pages qui n'existent pas encore. Souvent, lorsque nous créons des articles, nous incluons des liens vers des pages qui doivent être créées, même si elles ne sont pas encore réalisées. Cela nous aide à garder une trace des choses qui doivent éventuellement être faites, bien que parfois il faille un certain temps pour revenir à elles. Vous devriez vous sentir libre de le faire! Il suffit de cliquer sur ces liens et vous serez redirigé directement dans l'éditeur de la nouvelle page.
+
Créer une sous-page
+
+

Près du coin supérieur droit de chaque article, il y a un menu déroulant "Avancé". Dans ce menu, il y a une option "Nouvelle sous-page". En cliquant sur cette option, elle ouvre l'éditeur de page pour la création d'une nouvelle page dont la page parente dans la hiérarchie du site est la page sur laquelle vous avez choisi "Nouvelle sous-page". Il suffit de définir le titre et de commencer à écrire le contenu de l'article.

+
+
Créer un clone
+
Vous pouvez également cloner une page existante en utilisant l'option "Cloner cette page" dans le menu déroulant "Cette page". En cliquant sur cette option, elle crée une copie de la page en cours, dont la page parent est identique à la page en cours, et ouvre l'éditeur sur cette page, où vous pouvez définir le titre de la page, ainsi que modifier le contenu de la page. Ceci est généralement un bon moyen d'ajouter une nouvelle page à une zone de référence existante du site, par exemple, parce qu'il vous procure une mise en page de l'échantillon pour le contenu.
+
Créer un lien vers une page qui n'existe pas, puis cliquer dessus
+
Ceci est un peu une méthode hybride. Etant donné que chaque page doit être liée à partir d'une source, vous pourriez commencer par créer un lien vers le nouvel article en l'ajoutant à une page existante, puis, après avoir sauvé cette page, vous pouvez cliquer sur le lien que vous venez d'insérer pour ouvrir un éditeur pour le nouvel article.
+
+ +
+

Note : si vous n'êtes pas connecté, vous obtiendrez une erreur 404 lorsque vous essayez de visiter un article qui n'existe pas, au lieu d'un éditeur pour créer une nouvelle page.

+
+ +

Trouver l'information

+ +

Il y a beaucoup d'informations un peu partout, et il peut être difficile de trouver l'aide dont vous avez besoin. Voici quelques conseils pour vous aider à démarrer.

+ +
+
Liste des propriétaire des Modules
+
Les projets Mozilla travaillent sur une base "de propriétaire de module"; chaque composant majeur a un propriétaire ou des propriétaires qui sont responsables de ce qui se passe là-bas. Ces propriétaires sont souvent la meilleure source d'informations - ou au moins un excellent moyen de trouver la bonne personne à qui parler.
+
Mozilla source cross-reference
+
MXR, le Mozilla cross-reference, vous permet d'accéder à tout le code source pour le projet Mozilla (à l'exception de certaines choses, comme le projet Firefox OS, qui est situé sur GitHub). Le code et ses commentaires sont souvent une excellente source d'informations.
+
Mozilla wiki
+
Le wiki de Mozilla - souvent désigné comme "wikimo" - est un référentiel de processus et de conception de notes, projets, plans et devis préliminaires. En dépit d'être souvent un désordre encombré, il est un trésor de renseignements précieux.
+
-- cgit v1.2.3-54-g00ecf