From f6f0c1509a262eb9a5e7bd5d1a84a7b24551eee6 Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 11 Nov 2021 06:45:13 +0100 Subject: move *.html to *.md --- files/fr/mdn/about/index.html | 31 -- files/fr/mdn/about/index.md | 31 ++ files/fr/mdn/at_ten/history_of_mdn/index.html | 189 -------- files/fr/mdn/at_ten/history_of_mdn/index.md | 189 ++++++++ files/fr/mdn/at_ten/index.html | 36 -- files/fr/mdn/at_ten/index.md | 36 ++ .../contribute/documentation_priorities/index.html | 222 --------- .../contribute/documentation_priorities/index.md | 222 +++++++++ files/fr/mdn/contribute/feedback/index.html | 67 --- files/fr/mdn/contribute/feedback/index.md | 67 +++ files/fr/mdn/contribute/getting_started/index.html | 59 --- files/fr/mdn/contribute/getting_started/index.md | 59 +++ .../fr/mdn/contribute/github_beginners/index.html | 438 ------------------ files/fr/mdn/contribute/github_beginners/index.md | 438 ++++++++++++++++++ .../contribute/github_best_practices/index.html | 49 -- .../mdn/contribute/github_best_practices/index.md | 49 ++ .../fr/mdn/contribute/github_cheatsheet/index.html | 82 ---- files/fr/mdn/contribute/github_cheatsheet/index.md | 82 ++++ files/fr/mdn/contribute/help_beginners/index.html | 111 ----- files/fr/mdn/contribute/help_beginners/index.md | 111 +++++ .../convert_code_samples_to_be_live/index.html | 27 -- .../howto/convert_code_samples_to_be_live/index.md | 27 ++ .../howto/create_and_edit_pages/index.html | 44 -- .../howto/create_and_edit_pages/index.md | 44 ++ files/fr/mdn/contribute/howto/index.html | 13 - files/fr/mdn/contribute/howto/index.md | 13 + .../write_a_new_entry_in_the_glossary/index.html | 112 ----- .../write_a_new_entry_in_the_glossary/index.md | 112 +++++ files/fr/mdn/contribute/index.html | 112 ----- files/fr/mdn/contribute/index.md | 112 +++++ files/fr/mdn/contribute/localize/index.html | 71 --- files/fr/mdn/contribute/localize/index.md | 71 +++ .../contribute/open_source_etiquette/index.html | 165 ------- .../mdn/contribute/open_source_etiquette/index.md | 165 +++++++ files/fr/mdn/contribute/processes/index.html | 16 - files/fr/mdn/contribute/processes/index.md | 16 + .../mdn/contribute/where_is_everything/index.html | 35 -- .../fr/mdn/contribute/where_is_everything/index.md | 35 ++ .../mdn/guidelines/code_guidelines/css/index.html | 255 ----------- .../fr/mdn/guidelines/code_guidelines/css/index.md | 255 +++++++++++ .../guidelines/code_guidelines/general/index.html | 167 ------- .../guidelines/code_guidelines/general/index.md | 167 +++++++ .../mdn/guidelines/code_guidelines/html/index.html | 162 ------- .../mdn/guidelines/code_guidelines/html/index.md | 162 +++++++ files/fr/mdn/guidelines/code_guidelines/index.html | 64 --- files/fr/mdn/guidelines/code_guidelines/index.md | 64 +++ .../code_guidelines/javascript/index.html | 501 --------------------- .../guidelines/code_guidelines/javascript/index.md | 501 +++++++++++++++++++++ .../guidelines/code_guidelines/shell/index.html | 37 -- .../mdn/guidelines/code_guidelines/shell/index.md | 37 ++ .../guidelines/conventions_definitions/index.html | 175 ------- .../guidelines/conventions_definitions/index.md | 175 +++++++ .../guidelines/does_this_belong_on_mdn/index.html | 87 ---- .../guidelines/does_this_belong_on_mdn/index.md | 87 ++++ files/fr/mdn/guidelines/editorial/index.html | 37 -- files/fr/mdn/guidelines/editorial/index.md | 37 ++ files/fr/mdn/guidelines/index.html | 14 - files/fr/mdn/guidelines/index.md | 14 + files/fr/mdn/guidelines/video/index.html | 230 ---------- files/fr/mdn/guidelines/video/index.md | 230 ++++++++++ .../mdn/guidelines/writing_style_guide/index.html | 124 ----- .../fr/mdn/guidelines/writing_style_guide/index.md | 124 +++++ files/fr/mdn/index.html | 35 -- files/fr/mdn/index.md | 35 ++ files/fr/mdn/structures/index.html | 17 - files/fr/mdn/structures/index.md | 17 + files/fr/mdn/structures/live_samples/index.html | 171 ------- files/fr/mdn/structures/live_samples/index.md | 171 +++++++ .../macros/commonly-used_macros/index.html | 208 --------- .../macros/commonly-used_macros/index.md | 208 +++++++++ files/fr/mdn/structures/macros/index.html | 41 -- files/fr/mdn/structures/macros/index.md | 41 ++ files/fr/mdn/tools/index.html | 16 - files/fr/mdn/tools/index.md | 16 + files/fr/mdn/yari/index.html | 25 - files/fr/mdn/yari/index.md | 25 + 76 files changed, 4245 insertions(+), 4245 deletions(-) delete mode 100644 files/fr/mdn/about/index.html create mode 100644 files/fr/mdn/about/index.md delete mode 100644 files/fr/mdn/at_ten/history_of_mdn/index.html create mode 100644 files/fr/mdn/at_ten/history_of_mdn/index.md delete mode 100644 files/fr/mdn/at_ten/index.html create mode 100644 files/fr/mdn/at_ten/index.md delete mode 100644 files/fr/mdn/contribute/documentation_priorities/index.html create mode 100644 files/fr/mdn/contribute/documentation_priorities/index.md delete mode 100644 files/fr/mdn/contribute/feedback/index.html create mode 100644 files/fr/mdn/contribute/feedback/index.md delete mode 100644 files/fr/mdn/contribute/getting_started/index.html create mode 100644 files/fr/mdn/contribute/getting_started/index.md delete mode 100644 files/fr/mdn/contribute/github_beginners/index.html create mode 100644 files/fr/mdn/contribute/github_beginners/index.md delete mode 100644 files/fr/mdn/contribute/github_best_practices/index.html create mode 100644 files/fr/mdn/contribute/github_best_practices/index.md delete mode 100644 files/fr/mdn/contribute/github_cheatsheet/index.html create mode 100644 files/fr/mdn/contribute/github_cheatsheet/index.md delete mode 100644 files/fr/mdn/contribute/help_beginners/index.html create mode 100644 files/fr/mdn/contribute/help_beginners/index.md delete mode 100644 files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.html create mode 100644 files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.md delete mode 100644 files/fr/mdn/contribute/howto/create_and_edit_pages/index.html create mode 100644 files/fr/mdn/contribute/howto/create_and_edit_pages/index.md delete mode 100644 files/fr/mdn/contribute/howto/index.html create mode 100644 files/fr/mdn/contribute/howto/index.md delete 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_a_new_entry_in_the_glossary/index.md delete mode 100644 files/fr/mdn/contribute/index.html create mode 100644 files/fr/mdn/contribute/index.md delete mode 100644 files/fr/mdn/contribute/localize/index.html create mode 100644 files/fr/mdn/contribute/localize/index.md delete mode 100644 files/fr/mdn/contribute/open_source_etiquette/index.html create mode 100644 files/fr/mdn/contribute/open_source_etiquette/index.md delete mode 100644 files/fr/mdn/contribute/processes/index.html create mode 100644 files/fr/mdn/contribute/processes/index.md delete mode 100644 files/fr/mdn/contribute/where_is_everything/index.html create mode 100644 files/fr/mdn/contribute/where_is_everything/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/css/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/css/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/general/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/general/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/html/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/html/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/javascript/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/javascript/index.md delete mode 100644 files/fr/mdn/guidelines/code_guidelines/shell/index.html create mode 100644 files/fr/mdn/guidelines/code_guidelines/shell/index.md delete mode 100644 files/fr/mdn/guidelines/conventions_definitions/index.html create mode 100644 files/fr/mdn/guidelines/conventions_definitions/index.md delete mode 100644 files/fr/mdn/guidelines/does_this_belong_on_mdn/index.html create mode 100644 files/fr/mdn/guidelines/does_this_belong_on_mdn/index.md delete mode 100644 files/fr/mdn/guidelines/editorial/index.html create mode 100644 files/fr/mdn/guidelines/editorial/index.md delete mode 100644 files/fr/mdn/guidelines/index.html create mode 100644 files/fr/mdn/guidelines/index.md delete mode 100644 files/fr/mdn/guidelines/video/index.html create mode 100644 files/fr/mdn/guidelines/video/index.md delete mode 100644 files/fr/mdn/guidelines/writing_style_guide/index.html create mode 100644 files/fr/mdn/guidelines/writing_style_guide/index.md delete mode 100644 files/fr/mdn/index.html create mode 100644 files/fr/mdn/index.md delete mode 100644 files/fr/mdn/structures/index.html create mode 100644 files/fr/mdn/structures/index.md delete mode 100644 files/fr/mdn/structures/live_samples/index.html create mode 100644 files/fr/mdn/structures/live_samples/index.md delete mode 100644 files/fr/mdn/structures/macros/commonly-used_macros/index.html create mode 100644 files/fr/mdn/structures/macros/commonly-used_macros/index.md delete mode 100644 files/fr/mdn/structures/macros/index.html create mode 100644 files/fr/mdn/structures/macros/index.md delete mode 100644 files/fr/mdn/tools/index.html create mode 100644 files/fr/mdn/tools/index.md delete mode 100644 files/fr/mdn/yari/index.html create mode 100644 files/fr/mdn/yari/index.md (limited to 'files/fr/mdn') diff --git a/files/fr/mdn/about/index.html b/files/fr/mdn/about/index.html deleted file mode 100644 index a39a1964a8..0000000000 --- a/files/fr/mdn/about/index.html +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: À propos -slug: MDN/About -tags: - - MDN -translation_of: MDN/About -original_slug: MDN/A_propos ---- -
{{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/about/index.md b/files/fr/mdn/about/index.md new file mode 100644 index 0000000000..a39a1964a8 --- /dev/null +++ b/files/fr/mdn/about/index.md @@ -0,0 +1,31 @@ +--- +title: À propos +slug: MDN/About +tags: + - MDN +translation_of: MDN/About +original_slug: MDN/A_propos +--- +
{{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/at_ten/history_of_mdn/index.html b/files/fr/mdn/at_ten/history_of_mdn/index.html deleted file mode 100644 index b127966556..0000000000 --- a/files/fr/mdn/at_ten/history_of_mdn/index.html +++ /dev/null @@ -1,189 +0,0 @@ ---- -title: L'histoire de MDN -slug: MDN/At_ten/History_of_MDN -tags: - - MDN -translation_of: MDN_at_ten/History_of_MDN -original_slug: MDN_a_dix_ans/Histoire_MDN ---- -

Lors de cette discussion (en anglais), plusieurs contributeurs au projet MDN regardent dans le rétroviseur des dix dernières années de developer.mozilla.org et imaginent la décennie à venir. Vous pourrez entendre l'histoire des différentes migrations entre les logiciels de wiki, la façon dont la communauté a été construite et découvrir de nombreuses anecdotes de l'histoire du site. Le groupe réuni discute également des défis actuels et des projets sur lesquels la communauté MDN travaille cette année.

- -

Audio

- - - - - - -

{{ EmbedLiveSample('Audio', 'auto', '50px') }}

- -

Dans la suite de cette article, vous pourrez en savoir plus sur les personnes qui ont pris part à cette discussion et qui partagent leurs souvenirs et leurs pensées à propos de MDN. Cela vous permettra de découvrir les personnes qui forment une partie de la communauté de MDN.

- - -

Justin Crawford Product Manager, MDN

- -

Justin Crawford

- -

Justin anime cette discussion. Il fait des trucs avec du code, des mots, des morceaux de vélos et avec du bois. Sur Twitter, c'est @hoosteeno.

- - -

Qu'est-ce que MDN ? À qui s'adresse-t-il ? Un endroit pour la communauté du Web ouvert

- -

MDN fournit de nombreuses informations sur les technologies web et encourage l'apprentissage, le partage et l'enseignement des notions liées au Web ouvert. Sur MDN, vous pouvez contribuer pour vous-même et pour les autres.

-Un endroit pour les développeurs Mozilla - -

MDN est également un lieu destiné aux ingénieurs de Mozilla (qui travaillent par exemple sur Gecko ou Firefox), aux développeurs de modules complémentaires et aux contributeurs de Firefox OS.

- -

Eric "Sheppy" Shepherd Écrivain technique, MDN

- -

Eric Shepherd

- -

Sheppy écrit de la documentation pour Mozilla depuis 2006, il connaît une grande partie de l'histoire de MDC / MDN et surtout de nombreuses anecdotes. Sur Twitter, c'est @sheppy.

- -

L'histoire de MDN L'ère pré-wiki – Netscape DevEdge

- -

Au commencement était DevEdge, la documentation pour développeurs de Netscape. Ce fut la base pour une partie de la documentation de MDN. Vous pouvez vous plonger dans le passé grâce à archive.org :

- -

Netscape DevEdge

- -

Le 12 octobre 2004, ce site, populaire parmi les développeurs, fut fermé par AOL, l'entreprise à l'origine de Netscape. Quelques mois plus tard, en février 2005, Mitchell Baker put secourir DevEdge suite à un accord avec AOL qui permit à Mozilla de publier, modifier et de créer de nouveaux documents à partir du contenu du défunt Netscape DevEdge. Autrement dit, ce qui se produisit pour le code de Mozilla en 1998 s'appliqua également à la documentation Netscape pour les développeurs : elle est devenue open source.

- -

Deb Richardson rejoignit la Fondation Mozilla comme éditeur technique pour diriger le nouveau projet DevMo. Le but de ce projet : organiser de la documentation pour les développeurs grâce à la communauté.

- -

MediaWiki Le premier moteur wiki

- -

Grâce à MediaWiki qui fut la première plateforme utilisée pour ce nouveau projet, la documentation de Mozilla à destination des développeurs est rendue éditable à partir de juillet 2005. Une nouvelle brique collaborative vient s'ajouter au projet Mozilla et chacun est le bienvenu pour bâtir, améliorer cette ressource et partager ses connaissances. Une nouvelle communauté voit le jour à l'échelle internationale qui traduit le contenu dans d'autres langues.

- -

MDC MediaWiki

- -

Florian Scholz Écrivain technique, MDN

- -

Florian Scholz

-

Florian est un écrivain technique, employé à Mozilla et orienté vers les technologies web. Il prend soin de ce wiki comme certains prendraient soin d'un jardin, en cultivant la documentation et en tutorant la communauté avec laquelle il aime travailler afin que la documentation soit accessible au plus grand nombre. Florian est passioné d'open source, il est basé à Brême en Allemagne. Ses tweets sont signés avec l'alias @floscholz.

- -

DekiWiki Le deuxième moteur wiki

- -

En août 2008, le Mozilla Developer Center passa à MindTouch DekiWiki, un nouveau système de gestion de contenu et un système de wiki pour de la documentation technique. Cette plateforme fut sujette à controverse car la communauté qui utilisait MediaWiki depuis 2005 avait construit de nombreux outils autour de cette plateforme.

- -

MDC DekiWiki

- -

Ali Spivak Gardienne des supers chats de MDN

- -

Ali Spivak

- -

Ali Spivak gère le contenu et la communauté du Mozilla Developer Network. Elle passe son temps à réfléchir aux moyens de rendre le Web encore plus génial. Elle est passionnée lorsqu'il s'agit de maintenir un Web ouvert et libre. Après avoir versé dans l'open source lorsqu'elle a rejoint Mozilla en 2012, elle se concentre sur la construction et la participation des communautés de développeurs à Mozilla. Sur Twitter, c'est @alispivak.

- -

Kuma Le troisième (et actuel) moteur wiki

- -

Kuma, qui fut une fourche de Kitsune début 2011, fut lancé le 3 août 2012. C'est une plateforme construite par Mozilla pour gérer un wiki, celle-ci est basée sur Django et utilise son propre système de macro, appelé KumaScript et qui est basé sur Node.js.

- -

Le code étant disponible sur GitHub, la communauté commença également à contribuer au logiciel derrière MDN. Désormais, contribuer et bidouiller sur MDN concerne aussi bien la documentation que le développement sur Kuma.

- -

MDN KUMA

- -

David Walsh Développeur web, MDN

- -

David Walsh

- -

Développeur web sénior à Mozilla, ingénieur front-end, développeur principal de MooTools, fanatique de JavaScript, bidouilleur PHP et bricoleur CSS, amoureux du Web et de l'open source, David est @davidwalshblog sur Twitter.

- -

Refondre MDN Kuma, rafraîchi

- -

La refonte de MDN fut un gros projet. Sean Martell créa la nouvelle identité visuelle de MDN. Ce fut un processus itératif auquel prit part un groupe de 3000 beta-testeurs, durant plusieurs mois. Le nouveau style du site était « caché » derrière une option (« Waffle flag », le nom du système qui gère les options activées ou non dans MDN). Un grand bravo à David Walsh qui fut le principal acteur de cette refonte et qui offrit à MDN le style qu'il méritait.

-Waffle flag - -

Janet Swisher Community Manager, MDN

- -

Janet Swisher

- -

Janet est community manager à Mozilla pour MDN. Elle a rejoint Mozilla en 2004 et participe à des projets autour des logiciels open source depuis 2004. Elle travaille sur la communication technique depuis le XXe siècle. Elle vit à Austin au Texas (aux États-Unis) avec son mari et un caniche. Sur Twitter, c'est @jmswisher.

- -

La communauté autour de la documentation du Web Une documentation construite par la communauté et agnostique pour les différents navigateurs

- -

En 2010, notamment lorsque les membres de la communauté et les écrivains techniques se sont recontrés à Paris, MDN changea de direction : « Documenter tout sur Firefox ! » devint « Documenter tout sur le Web ». C'est pourquoi, ces dernières années, la documentation a été revue, nettoyée et réorganisée pour que la documentation de MDN à propos du Web soit agnostique quant aux navigateurs. De cette façon, MDN est une ressource utile pour n'importe quel développeur web. C'est la partie de MDN consacrée au Web qui est la plus populaire et la plus utilisée.

- -

Les différentes organisations à l'origine des différents navigateurs ont depuis participé au contenu de MDN. Cette collaboration autour des différents navigateurs est très appréciée des lecteurs de MDN.

- -

Luke Crouch développeur web, MDN

- -

Luke Crouch

- -

Luke Crouch brasse sa propre bière, est fan de football et est développeur web à Mozilla. Il développe sur le Web depuis 1996, utilise Firefox depuis 2004, écrit des logiciels open source depuis 2006 et a rejoint Mozilla comme premier développeur web pour MDN en 2010. Sur Twitter, Luke est @groovecoder.

- -

Les communautés de localisation MDN sert un public mondial, dans de nombreuses langues

- -

La localisation est une pierre angulaire de la communauté Mozilla. Elle fait partie de presque tous les projets et tous les produits. Grâce à Kuma, MDN est localisable et répond aux besoin de notre communauté l10n. Les spécifications W3C et les autres ressources qui décrivent les fonctionnalités du Web n'ont parfois pas d'autres fins et sont donc uniquement disponibles en anglais. Pour les développeurs avancés mais aussi et surtout pour les débutants, MDN peut permettre d'explorer les technologies du Web. C'est donc notre but que d'être disponible pour tout le monde. MDN possède un public mondial et ne vise pas uniquement les anglophones. Grâce aux efforts de traduction et de localisation, MDN est apprécié tout autour du globe.

- -

Julien (alias Sphinx) Localisation en français, MDN

- -

Julien

- -

Julien a passé de nombreuses soirées et week-ends, pendant plusieurs mois à traduire et à maintenir les articles sur JavaScript en français. Il n'est pas développeur mais possède des connaissances en informatique et souhaite apprendre ce qui tourne autour des nouvelles technologies. Plutôt que de regarder la télé, il contribue à MDN.

- -

Jean-Yves Perrier Écrivain technique, MDN

- -

Jean-Yves Perrier

- -

Jean-Yves est écrivain technique sur MDN depuis 2010, il a rejoint Mozilla à plein temps fin 2011. Il est passioné par le Web et a 15 ans d'expérience en C++. Il est Suisse et vit à Londres au Royaume-Uni. Son indice d'Erdös vaut 5 et sur Twitter, c'est @Teoli2003.

- - -

« Learning Area » ou Apprendre le Web

- -

La Learning Area est un nouveau projet de MDN pour enseigner les compétences de base autour du Web. Ces 10 dernières années, MDN a mis à disposition beaucoup de contenu avancé, permettant aux experts de travailler avec des informations précises. Ce projet est à destination des débutants et vise à combler les manques vis-à-vis de ce public.

- -

Jérémie Patonnier Écrivain technique, MDN

- -

Jérémie Patonnier

- -

Jérémie est, depuis longtemps, un contributeur à MDN. C'est un développeur web professionnel depuis 2000. Il milite en faveur des standards du Web et écrit de la documentation sur les technologies web avec la volonté qu'elle soit accessible à tout le monde. Sur Twitter, c'est @JeremiePat.

- -

Le futur de MDN Qu'est-ce qui sera différent lors des 20 ans de MDN ?

- -

Toutes les personnes qui sont impliquées au sein de MDN souhaitent vraiment que le Web soit ouvert et accessible à tous. C'est pour cela que nous avons de nombreux contributeurs et équipes de localisation. MDN espère continuer à jouer un rôle important pour que le Web continue à être ce que nous aimerions qu'il soit.

- -

Une grande partie de cet avenir se jouera sur les ressources d'apprentissage. Ces dix prochaines années, nous verrons de plus en plus de développeurs web.

- -

Une autre partie, toute aussi importante, est de maintenir et de mettre à jour le contenu déjà présent sur MDN. Grâce à cela, les développeurs web pourront toujours bénéficier d'un contenu précis et pertinent.

- -

Ce qui change et qui va probablement continuer à changer, c'est la façon dont l'information est consommée. Aujourd'hui, les personnes recherchent des informations et parcourent la documentation. Demain, MDN pourrait être diffusé via les édidteurs de code, les outils de développement Firefox, via d'autres services et outils, etc.

- -

Des contributeurs exceptionnels Beaucoup d'autres personnes ont accompli un travail formidable sur MDN

- - - - - - -The Berlin Office - diff --git a/files/fr/mdn/at_ten/history_of_mdn/index.md b/files/fr/mdn/at_ten/history_of_mdn/index.md new file mode 100644 index 0000000000..b127966556 --- /dev/null +++ b/files/fr/mdn/at_ten/history_of_mdn/index.md @@ -0,0 +1,189 @@ +--- +title: L'histoire de MDN +slug: MDN/At_ten/History_of_MDN +tags: + - MDN +translation_of: MDN_at_ten/History_of_MDN +original_slug: MDN_a_dix_ans/Histoire_MDN +--- +

Lors de cette discussion (en anglais), plusieurs contributeurs au projet MDN regardent dans le rétroviseur des dix dernières années de developer.mozilla.org et imaginent la décennie à venir. Vous pourrez entendre l'histoire des différentes migrations entre les logiciels de wiki, la façon dont la communauté a été construite et découvrir de nombreuses anecdotes de l'histoire du site. Le groupe réuni discute également des défis actuels et des projets sur lesquels la communauté MDN travaille cette année.

+ +

Audio

+ + + + + + +

{{ EmbedLiveSample('Audio', 'auto', '50px') }}

+ +

Dans la suite de cette article, vous pourrez en savoir plus sur les personnes qui ont pris part à cette discussion et qui partagent leurs souvenirs et leurs pensées à propos de MDN. Cela vous permettra de découvrir les personnes qui forment une partie de la communauté de MDN.

+ + +

Justin Crawford Product Manager, MDN

+ +

Justin Crawford

+ +

Justin anime cette discussion. Il fait des trucs avec du code, des mots, des morceaux de vélos et avec du bois. Sur Twitter, c'est @hoosteeno.

+ + +

Qu'est-ce que MDN ? À qui s'adresse-t-il ? Un endroit pour la communauté du Web ouvert

+ +

MDN fournit de nombreuses informations sur les technologies web et encourage l'apprentissage, le partage et l'enseignement des notions liées au Web ouvert. Sur MDN, vous pouvez contribuer pour vous-même et pour les autres.

+Un endroit pour les développeurs Mozilla + +

MDN est également un lieu destiné aux ingénieurs de Mozilla (qui travaillent par exemple sur Gecko ou Firefox), aux développeurs de modules complémentaires et aux contributeurs de Firefox OS.

+ +

Eric "Sheppy" Shepherd Écrivain technique, MDN

+ +

Eric Shepherd

+ +

Sheppy écrit de la documentation pour Mozilla depuis 2006, il connaît une grande partie de l'histoire de MDC / MDN et surtout de nombreuses anecdotes. Sur Twitter, c'est @sheppy.

+ +

L'histoire de MDN L'ère pré-wiki – Netscape DevEdge

+ +

Au commencement était DevEdge, la documentation pour développeurs de Netscape. Ce fut la base pour une partie de la documentation de MDN. Vous pouvez vous plonger dans le passé grâce à archive.org :

+ +

Netscape DevEdge

+ +

Le 12 octobre 2004, ce site, populaire parmi les développeurs, fut fermé par AOL, l'entreprise à l'origine de Netscape. Quelques mois plus tard, en février 2005, Mitchell Baker put secourir DevEdge suite à un accord avec AOL qui permit à Mozilla de publier, modifier et de créer de nouveaux documents à partir du contenu du défunt Netscape DevEdge. Autrement dit, ce qui se produisit pour le code de Mozilla en 1998 s'appliqua également à la documentation Netscape pour les développeurs : elle est devenue open source.

+ +

Deb Richardson rejoignit la Fondation Mozilla comme éditeur technique pour diriger le nouveau projet DevMo. Le but de ce projet : organiser de la documentation pour les développeurs grâce à la communauté.

+ +

MediaWiki Le premier moteur wiki

+ +

Grâce à MediaWiki qui fut la première plateforme utilisée pour ce nouveau projet, la documentation de Mozilla à destination des développeurs est rendue éditable à partir de juillet 2005. Une nouvelle brique collaborative vient s'ajouter au projet Mozilla et chacun est le bienvenu pour bâtir, améliorer cette ressource et partager ses connaissances. Une nouvelle communauté voit le jour à l'échelle internationale qui traduit le contenu dans d'autres langues.

+ +

MDC MediaWiki

+ +

Florian Scholz Écrivain technique, MDN

+ +

Florian Scholz

+

Florian est un écrivain technique, employé à Mozilla et orienté vers les technologies web. Il prend soin de ce wiki comme certains prendraient soin d'un jardin, en cultivant la documentation et en tutorant la communauté avec laquelle il aime travailler afin que la documentation soit accessible au plus grand nombre. Florian est passioné d'open source, il est basé à Brême en Allemagne. Ses tweets sont signés avec l'alias @floscholz.

+ +

DekiWiki Le deuxième moteur wiki

+ +

En août 2008, le Mozilla Developer Center passa à MindTouch DekiWiki, un nouveau système de gestion de contenu et un système de wiki pour de la documentation technique. Cette plateforme fut sujette à controverse car la communauté qui utilisait MediaWiki depuis 2005 avait construit de nombreux outils autour de cette plateforme.

+ +

MDC DekiWiki

+ +

Ali Spivak Gardienne des supers chats de MDN

+ +

Ali Spivak

+ +

Ali Spivak gère le contenu et la communauté du Mozilla Developer Network. Elle passe son temps à réfléchir aux moyens de rendre le Web encore plus génial. Elle est passionnée lorsqu'il s'agit de maintenir un Web ouvert et libre. Après avoir versé dans l'open source lorsqu'elle a rejoint Mozilla en 2012, elle se concentre sur la construction et la participation des communautés de développeurs à Mozilla. Sur Twitter, c'est @alispivak.

+ +

Kuma Le troisième (et actuel) moteur wiki

+ +

Kuma, qui fut une fourche de Kitsune début 2011, fut lancé le 3 août 2012. C'est une plateforme construite par Mozilla pour gérer un wiki, celle-ci est basée sur Django et utilise son propre système de macro, appelé KumaScript et qui est basé sur Node.js.

+ +

Le code étant disponible sur GitHub, la communauté commença également à contribuer au logiciel derrière MDN. Désormais, contribuer et bidouiller sur MDN concerne aussi bien la documentation que le développement sur Kuma.

+ +

MDN KUMA

+ +

David Walsh Développeur web, MDN

+ +

David Walsh

+ +

Développeur web sénior à Mozilla, ingénieur front-end, développeur principal de MooTools, fanatique de JavaScript, bidouilleur PHP et bricoleur CSS, amoureux du Web et de l'open source, David est @davidwalshblog sur Twitter.

+ +

Refondre MDN Kuma, rafraîchi

+ +

La refonte de MDN fut un gros projet. Sean Martell créa la nouvelle identité visuelle de MDN. Ce fut un processus itératif auquel prit part un groupe de 3000 beta-testeurs, durant plusieurs mois. Le nouveau style du site était « caché » derrière une option (« Waffle flag », le nom du système qui gère les options activées ou non dans MDN). Un grand bravo à David Walsh qui fut le principal acteur de cette refonte et qui offrit à MDN le style qu'il méritait.

+Waffle flag + +

Janet Swisher Community Manager, MDN

+ +

Janet Swisher

+ +

Janet est community manager à Mozilla pour MDN. Elle a rejoint Mozilla en 2004 et participe à des projets autour des logiciels open source depuis 2004. Elle travaille sur la communication technique depuis le XXe siècle. Elle vit à Austin au Texas (aux États-Unis) avec son mari et un caniche. Sur Twitter, c'est @jmswisher.

+ +

La communauté autour de la documentation du Web Une documentation construite par la communauté et agnostique pour les différents navigateurs

+ +

En 2010, notamment lorsque les membres de la communauté et les écrivains techniques se sont recontrés à Paris, MDN changea de direction : « Documenter tout sur Firefox ! » devint « Documenter tout sur le Web ». C'est pourquoi, ces dernières années, la documentation a été revue, nettoyée et réorganisée pour que la documentation de MDN à propos du Web soit agnostique quant aux navigateurs. De cette façon, MDN est une ressource utile pour n'importe quel développeur web. C'est la partie de MDN consacrée au Web qui est la plus populaire et la plus utilisée.

+ +

Les différentes organisations à l'origine des différents navigateurs ont depuis participé au contenu de MDN. Cette collaboration autour des différents navigateurs est très appréciée des lecteurs de MDN.

+ +

Luke Crouch développeur web, MDN

+ +

Luke Crouch

+ +

Luke Crouch brasse sa propre bière, est fan de football et est développeur web à Mozilla. Il développe sur le Web depuis 1996, utilise Firefox depuis 2004, écrit des logiciels open source depuis 2006 et a rejoint Mozilla comme premier développeur web pour MDN en 2010. Sur Twitter, Luke est @groovecoder.

+ +

Les communautés de localisation MDN sert un public mondial, dans de nombreuses langues

+ +

La localisation est une pierre angulaire de la communauté Mozilla. Elle fait partie de presque tous les projets et tous les produits. Grâce à Kuma, MDN est localisable et répond aux besoin de notre communauté l10n. Les spécifications W3C et les autres ressources qui décrivent les fonctionnalités du Web n'ont parfois pas d'autres fins et sont donc uniquement disponibles en anglais. Pour les développeurs avancés mais aussi et surtout pour les débutants, MDN peut permettre d'explorer les technologies du Web. C'est donc notre but que d'être disponible pour tout le monde. MDN possède un public mondial et ne vise pas uniquement les anglophones. Grâce aux efforts de traduction et de localisation, MDN est apprécié tout autour du globe.

+ +

Julien (alias Sphinx) Localisation en français, MDN

+ +

Julien

+ +

Julien a passé de nombreuses soirées et week-ends, pendant plusieurs mois à traduire et à maintenir les articles sur JavaScript en français. Il n'est pas développeur mais possède des connaissances en informatique et souhaite apprendre ce qui tourne autour des nouvelles technologies. Plutôt que de regarder la télé, il contribue à MDN.

+ +

Jean-Yves Perrier Écrivain technique, MDN

+ +

Jean-Yves Perrier

+ +

Jean-Yves est écrivain technique sur MDN depuis 2010, il a rejoint Mozilla à plein temps fin 2011. Il est passioné par le Web et a 15 ans d'expérience en C++. Il est Suisse et vit à Londres au Royaume-Uni. Son indice d'Erdös vaut 5 et sur Twitter, c'est @Teoli2003.

+ + +

« Learning Area » ou Apprendre le Web

+ +

La Learning Area est un nouveau projet de MDN pour enseigner les compétences de base autour du Web. Ces 10 dernières années, MDN a mis à disposition beaucoup de contenu avancé, permettant aux experts de travailler avec des informations précises. Ce projet est à destination des débutants et vise à combler les manques vis-à-vis de ce public.

+ +

Jérémie Patonnier Écrivain technique, MDN

+ +

Jérémie Patonnier

+ +

Jérémie est, depuis longtemps, un contributeur à MDN. C'est un développeur web professionnel depuis 2000. Il milite en faveur des standards du Web et écrit de la documentation sur les technologies web avec la volonté qu'elle soit accessible à tout le monde. Sur Twitter, c'est @JeremiePat.

+ +

Le futur de MDN Qu'est-ce qui sera différent lors des 20 ans de MDN ?

+ +

Toutes les personnes qui sont impliquées au sein de MDN souhaitent vraiment que le Web soit ouvert et accessible à tous. C'est pour cela que nous avons de nombreux contributeurs et équipes de localisation. MDN espère continuer à jouer un rôle important pour que le Web continue à être ce que nous aimerions qu'il soit.

+ +

Une grande partie de cet avenir se jouera sur les ressources d'apprentissage. Ces dix prochaines années, nous verrons de plus en plus de développeurs web.

+ +

Une autre partie, toute aussi importante, est de maintenir et de mettre à jour le contenu déjà présent sur MDN. Grâce à cela, les développeurs web pourront toujours bénéficier d'un contenu précis et pertinent.

+ +

Ce qui change et qui va probablement continuer à changer, c'est la façon dont l'information est consommée. Aujourd'hui, les personnes recherchent des informations et parcourent la documentation. Demain, MDN pourrait être diffusé via les édidteurs de code, les outils de développement Firefox, via d'autres services et outils, etc.

+ +

Des contributeurs exceptionnels Beaucoup d'autres personnes ont accompli un travail formidable sur MDN

+ + + + + + +The Berlin Office + diff --git a/files/fr/mdn/at_ten/index.html b/files/fr/mdn/at_ten/index.html deleted file mode 100644 index 08e46f4829..0000000000 --- a/files/fr/mdn/at_ten/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: MDN a 10 ans -slug: MDN/At_ten -tags: - - 10 ans - - MDN -translation_of: MDN_at_ten -original_slug: MDN_a_dix_ans ---- -
-

Fêtons 10 années passées à documenter votre Web.

-
- -

L'histoire de MDN

- -

Début 2005, une petite equipe de développeurs Web ont crée une ressource libre et construite de façon communautaire. Cette idée brillante et décalée par rapport à cette époque est aujourd'hui devenue Mozilla Developer Network — la meilleure ressource pour toutes les technologies ouvertes du Web. Dix ans plus tard, notre communauté est toujours plus grande et présente sur toute la planète. Ensemble, nous continuons à créer de la documentation, des exemples de code et des ressources d'apprentissage pour toutes les technologies du Web telles que CSS, HTML, JavaScript et tout ce qui fait le Web tel qu'il est :c'est à dire ouvert et puissant.

- -

En savoir plus

- - -

Contribuer à MDN

- -

Depuis 10 ans, la communauté MDN documente le Web. Qu'il s'agisse de corriger quelques coquilles ou d'écrire des articles entiers pour documenter une nouvelle API, chacun a quelque chose à offrir et aucune contribution n'est trop petite ou trop grande. Nous avons plus de 90 000 pages de contenu qui ont été écrites ou traduites par des membres de notre communauté. Vous pouvez en faire partie.

- -

En savoir plus

- -
Quand je souhaite comprendre « pourquoi » plutôt que « comment », j'utilise MDN.
-— Christian Heilmann - - - -
    -
  1. MDN a 10 ans
    2. -
  2. L'histoire de MDN
    3. -
  3. Contribuer à MDN
    4. -
diff --git a/files/fr/mdn/at_ten/index.md b/files/fr/mdn/at_ten/index.md new file mode 100644 index 0000000000..08e46f4829 --- /dev/null +++ b/files/fr/mdn/at_ten/index.md @@ -0,0 +1,36 @@ +--- +title: MDN a 10 ans +slug: MDN/At_ten +tags: + - 10 ans + - MDN +translation_of: MDN_at_ten +original_slug: MDN_a_dix_ans +--- +
+

Fêtons 10 années passées à documenter votre Web.

+
+ +

L'histoire de MDN

+ +

Début 2005, une petite equipe de développeurs Web ont crée une ressource libre et construite de façon communautaire. Cette idée brillante et décalée par rapport à cette époque est aujourd'hui devenue Mozilla Developer Network — la meilleure ressource pour toutes les technologies ouvertes du Web. Dix ans plus tard, notre communauté est toujours plus grande et présente sur toute la planète. Ensemble, nous continuons à créer de la documentation, des exemples de code et des ressources d'apprentissage pour toutes les technologies du Web telles que CSS, HTML, JavaScript et tout ce qui fait le Web tel qu'il est :c'est à dire ouvert et puissant.

+ +

En savoir plus

+ + +

Contribuer à MDN

+ +

Depuis 10 ans, la communauté MDN documente le Web. Qu'il s'agisse de corriger quelques coquilles ou d'écrire des articles entiers pour documenter une nouvelle API, chacun a quelque chose à offrir et aucune contribution n'est trop petite ou trop grande. Nous avons plus de 90 000 pages de contenu qui ont été écrites ou traduites par des membres de notre communauté. Vous pouvez en faire partie.

+ +

En savoir plus

+ +
Quand je souhaite comprendre « pourquoi » plutôt que « comment », j'utilise MDN.
+— Christian Heilmann + + + +
    +
  1. MDN a 10 ans
    2. +
  2. L'histoire de MDN
    3. +
  3. Contribuer à MDN
    4. +
diff --git a/files/fr/mdn/contribute/documentation_priorities/index.html b/files/fr/mdn/contribute/documentation_priorities/index.html deleted file mode 100644 index 9f56f5fcaa..0000000000 --- a/files/fr/mdn/contribute/documentation_priorities/index.html +++ /dev/null @@ -1,222 +0,0 @@ ---- -title: Liste des priorités de la documentation de MDN -slug: MDN/Contribute/Documentation_priorities -tags: - - Best practices - - Community - - MDN - - Documentation - - Priorities -translation_of: MDN/Contribute/Documentation_priorities ---- -

{{MDNSidebar}}

- -

Ce document définit les différents niveaux de priorité sur MDN, et indique quels sujets de documentation existent dans chaque niveau - nous les catégorisons entre Niveau 1 et Niveau 2.

- -

L'objectif de ce document est double :

- - - -

L'importance relative de ces documents a été déterminée uniquement en fonction du nombre de pages vues. Il y a beaucoup de mesures que nous aurions pu utiliser, mais le nombre de pages vues est objectif et reste un bon indicateur. Les technologies web les plus importantes sont consultées plus souvent et, par conséquent, la résolution des problèmes liés à ces documents semble la plus importante.

- -

Gardez également à l'esprit que ces niveaux sont constitués d'arborescences de documents isolés (c'est-à-dire la page liée, plus tous les documents de la hiérarchie qui lui sont inférieurs). Il arrive qu'un document de niveau 1 soit lié à un document de niveau 2, ou vice versa, et c'est normal.

- -

Les chiffres entre parenthèses après chaque arbre de documents représentent le nombre de documents sous cet arbre pour l'anglais. Ces chiffres sont susceptibles de changer au fil du temps, et il faudra peut-être les revoir avant longtemps.

- -

Niveau 1

- -

Le contenu de niveau 1 est le plus important sur MDN : il compte le plus grand nombre de lectrices et lecteurs. Il est censé couvrir les technologies les plus importantes pour la plateforme web.

- - - -

Total des pages pour le niveau 1 : 4150

- -

Niveau 2

- -

Le contenu de niveau 2 est moins couramment utilisé, mais néanmoins utile.

- - - -

Total des pages pour le niveau 2 : 6502

- -

Autres contenus

- -

Il existe d'autres contenus sur MDN qui ne concernent pas la plateforme web (comme les contenus archivés, les documents spécifiques à Firefox sur les outils de développement ou les détails internes pour ce navigateur). Ce contenu a été complètement déprogrammé et, dans la plupart des cas, nous essayons de lui trouver une nouvelle place ou de le supprimer s'il n'est plus utile. Nous ne recommandons pas à notre communauté de consacrer du temps à des domaines qui ne sont pas explicitement répertoriés sur cette page.

- -

API Web niveau 1

- -

Les documents de référence pour les interfaces des API qui suivent (et leurs pages enfant) sont actuellement considérés comme étant de niveau 1. Pour plus d'informations sur la justification de ces regroupements et priorités, voir le travail effectué dans https://github.com/mdn/sprints/issues/3327.

- -

Canvas API (112)

- - - -

Clipboard API (13)

- - - -

DOM (439)

- -
-

Note : « DOM » n'est qu'un groupe partiel - nous n'avons inclus que les documents relatifs à l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre gérable. Les autres interfaces DOM qui ne figurent pas dans cette liste sont dans le niveau 2.

-
- - - -

DOM Events (22)

- -
-

Note : « DOM Events » n'est qu'un groupe partiel - nous n'avons inclus que les documents relatifs à l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre raisonnable. Les autres interfaces DOM Events qui ne figurent pas dans cette liste se trouvent au niveau 2.

-
- - - -

Fetch API (47)

- - - -

File API (48)

- - - -

HTML DOM (371)

- -
-

Note : « HTML DOM » n'est qu'un groupe partiel - nous n'avons inclus que les documents de l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre gérable. Les autres interfaces HTML DOM qui ne figurent pas dans cette liste sont dans le niveau 2.

-
- - - -

URL API (43)

- - - -

Web Storage API (8)

- - - -

WebSockets API (28)

- - - -

XMLHttpRequest (58)

- - diff --git a/files/fr/mdn/contribute/documentation_priorities/index.md b/files/fr/mdn/contribute/documentation_priorities/index.md new file mode 100644 index 0000000000..9f56f5fcaa --- /dev/null +++ b/files/fr/mdn/contribute/documentation_priorities/index.md @@ -0,0 +1,222 @@ +--- +title: Liste des priorités de la documentation de MDN +slug: MDN/Contribute/Documentation_priorities +tags: + - Best practices + - Community + - MDN + - Documentation + - Priorities +translation_of: MDN/Contribute/Documentation_priorities +--- +

{{MDNSidebar}}

+ +

Ce document définit les différents niveaux de priorité sur MDN, et indique quels sujets de documentation existent dans chaque niveau - nous les catégorisons entre Niveau 1 et Niveau 2.

+ +

L'objectif de ce document est double :

+ + + +

L'importance relative de ces documents a été déterminée uniquement en fonction du nombre de pages vues. Il y a beaucoup de mesures que nous aurions pu utiliser, mais le nombre de pages vues est objectif et reste un bon indicateur. Les technologies web les plus importantes sont consultées plus souvent et, par conséquent, la résolution des problèmes liés à ces documents semble la plus importante.

+ +

Gardez également à l'esprit que ces niveaux sont constitués d'arborescences de documents isolés (c'est-à-dire la page liée, plus tous les documents de la hiérarchie qui lui sont inférieurs). Il arrive qu'un document de niveau 1 soit lié à un document de niveau 2, ou vice versa, et c'est normal.

+ +

Les chiffres entre parenthèses après chaque arbre de documents représentent le nombre de documents sous cet arbre pour l'anglais. Ces chiffres sont susceptibles de changer au fil du temps, et il faudra peut-être les revoir avant longtemps.

+ +

Niveau 1

+ +

Le contenu de niveau 1 est le plus important sur MDN : il compte le plus grand nombre de lectrices et lecteurs. Il est censé couvrir les technologies les plus importantes pour la plateforme web.

+ + + +

Total des pages pour le niveau 1 : 4150

+ +

Niveau 2

+ +

Le contenu de niveau 2 est moins couramment utilisé, mais néanmoins utile.

+ + + +

Total des pages pour le niveau 2 : 6502

+ +

Autres contenus

+ +

Il existe d'autres contenus sur MDN qui ne concernent pas la plateforme web (comme les contenus archivés, les documents spécifiques à Firefox sur les outils de développement ou les détails internes pour ce navigateur). Ce contenu a été complètement déprogrammé et, dans la plupart des cas, nous essayons de lui trouver une nouvelle place ou de le supprimer s'il n'est plus utile. Nous ne recommandons pas à notre communauté de consacrer du temps à des domaines qui ne sont pas explicitement répertoriés sur cette page.

+ +

API Web niveau 1

+ +

Les documents de référence pour les interfaces des API qui suivent (et leurs pages enfant) sont actuellement considérés comme étant de niveau 1. Pour plus d'informations sur la justification de ces regroupements et priorités, voir le travail effectué dans https://github.com/mdn/sprints/issues/3327.

+ +

Canvas API (112)

+ + + +

Clipboard API (13)

+ + + +

DOM (439)

+ +
+

Note : « DOM » n'est qu'un groupe partiel - nous n'avons inclus que les documents relatifs à l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre gérable. Les autres interfaces DOM qui ne figurent pas dans cette liste sont dans le niveau 2.

+
+ + + +

DOM Events (22)

+ +
+

Note : « DOM Events » n'est qu'un groupe partiel - nous n'avons inclus que les documents relatifs à l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre raisonnable. Les autres interfaces DOM Events qui ne figurent pas dans cette liste se trouvent au niveau 2.

+
+ + + +

Fetch API (47)

+ + + +

File API (48)

+ + + +

HTML DOM (371)

+ +
+

Note : « HTML DOM » n'est qu'un groupe partiel - nous n'avons inclus que les documents de l'interface ayant le plus grand nombre de pages vues, afin de maintenir la taille du niveau 1 à un nombre gérable. Les autres interfaces HTML DOM qui ne figurent pas dans cette liste sont dans le niveau 2.

+
+ + + +

URL API (43)

+ + + +

Web Storage API (8)

+ + + +

WebSockets API (28)

+ + + +

XMLHttpRequest (58)

+ + diff --git a/files/fr/mdn/contribute/feedback/index.html b/files/fr/mdn/contribute/feedback/index.html deleted file mode 100644 index 29c900a3c5..0000000000 --- a/files/fr/mdn/contribute/feedback/index.html +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Faire un retour à propos de MDN Web Docs -slug: MDN/Contribute/Feedback -tags: - - Documentation - - Guide - - MDN - - MDN Meta -translation_of: MDN/Contribute/Feedback ---- -
{{MDNSidebar}}
- -

Bienvenue sur MDN Web Docs ! 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 pour porter votre voix, cet article vous les explique.

- -

Mettre à jour la documentation

- -

Tout d'abord, si vous avez constaté un problème dans la documentation, sentez vous libre de le corriger vous-même. Commencez par lire les étapes spécifiques pour se préparer à faire des contributions.

- -

Si vous souhaitez savoir comment contribuer aux traductions en français, vous pouvez également lire ce billet.

- -

Les sources de la documentation ici sont stockées dans GitHub, et gérées par une équipe de bénévoles et de salariés, alors ne soyez pas timide - votre grammaire n'a pas besoin d'être parfaite. Nous passerons en revue vos modifications et vous aiderons à corriger les erreurs éventuelles.

- -

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

- - - -

Rejoignez la conversation

- -

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

- -

Discussions en direct - chats

- -

Nous utilisons Matrix pour converser sur MDN et son contenu. Vous pouvez participer à la conversation !

- -
-
MDN Web Docs
-
Sur ce salon sont regroupés les membres de la communauté internationale de MDN, il est destiné aux discussions générales sur MDN : utilisation du site, lecture du contenu du site et contribution au contenu du site. Si vous avez des questions ou des commentaires sur le contenu des articles, sur les nouveaux articles que vous aimeriez voir ou créer, ou si vous voulez simplement parler avec l'équipe de rédaction, c'est l'endroit idéal. Il s'agit d'un canal anglophone, toutefois, des personnes francophones s'y trouvent généralement.
-
Localisation / traduction en français
-
Sur ce salon sont regroupés les membres de la communauté francophone de Mozilla (que ce soit pour Firefox, MDN ou d'autres sites ou outils).
-
- -

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.

- -

Signaler un problème

- -

Problèmes 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 signaler un problème. Vous pouvez utiliser ce formulaire pour tout problème avec la documentation, pas exemple :

- - - -

Comme évoqué plus haut, n'hésitez pas à contribuer vous-même pour corriger ces erreurs.

- -

Problèmes sur le site

- -

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

diff --git a/files/fr/mdn/contribute/feedback/index.md b/files/fr/mdn/contribute/feedback/index.md new file mode 100644 index 0000000000..29c900a3c5 --- /dev/null +++ b/files/fr/mdn/contribute/feedback/index.md @@ -0,0 +1,67 @@ +--- +title: Faire un retour à propos de MDN Web Docs +slug: MDN/Contribute/Feedback +tags: + - Documentation + - Guide + - MDN + - MDN Meta +translation_of: MDN/Contribute/Feedback +--- +
{{MDNSidebar}}
+ +

Bienvenue sur MDN Web Docs ! 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 pour porter votre voix, cet article vous les explique.

+ +

Mettre à jour la documentation

+ +

Tout d'abord, si vous avez constaté un problème dans la documentation, sentez vous libre de le corriger vous-même. Commencez par lire les étapes spécifiques pour se préparer à faire des contributions.

+ +

Si vous souhaitez savoir comment contribuer aux traductions en français, vous pouvez également lire ce billet.

+ +

Les sources de la documentation ici sont stockées dans GitHub, et gérées par une équipe de bénévoles et de salariés, alors ne soyez pas timide - votre grammaire n'a pas besoin d'être parfaite. Nous passerons en revue vos modifications et vous aiderons à corriger les erreurs éventuelles.

+ +

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

+ + + +

Rejoignez la conversation

+ +

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

+ +

Discussions en direct - chats

+ +

Nous utilisons Matrix pour converser sur MDN et son contenu. Vous pouvez participer à la conversation !

+ +
+
MDN Web Docs
+
Sur ce salon sont regroupés les membres de la communauté internationale de MDN, il est destiné aux discussions générales sur MDN : utilisation du site, lecture du contenu du site et contribution au contenu du site. Si vous avez des questions ou des commentaires sur le contenu des articles, sur les nouveaux articles que vous aimeriez voir ou créer, ou si vous voulez simplement parler avec l'équipe de rédaction, c'est l'endroit idéal. Il s'agit d'un canal anglophone, toutefois, des personnes francophones s'y trouvent généralement.
+
Localisation / traduction en français
+
Sur ce salon sont regroupés les membres de la communauté francophone de Mozilla (que ce soit pour Firefox, MDN ou d'autres sites ou outils).
+
+ +

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.

+ +

Signaler un problème

+ +

Problèmes 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 signaler un problème. Vous pouvez utiliser ce formulaire pour tout problème avec la documentation, pas exemple :

+ + + +

Comme évoqué plus haut, n'hésitez pas à contribuer vous-même pour corriger ces erreurs.

+ +

Problèmes sur le site

+ +

Si vous rencontrez un problème avec le site ou avez de nouvelles idées pour celui-ci, vous pouvez créer 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 deleted file mode 100644 index 563a36e2d7..0000000000 --- a/files/fr/mdn/contribute/getting_started/index.html +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Débuter sur MDN -slug: MDN/Contribute/Getting_started -tags: - - Documentation - - Getting Started - - Guide - - MDN - - MDN Project - - New Contributors -translation_of: MDN/Contribute/Getting_started ---- -
{{MDNSidebar}}
- -

Nous sommes une communauté ouverte de développeuses et développeurs qui créent des ressources pour un meilleur Web, quelle que soit la marque, le navigateur ou la plate-forme. Tout le monde peut contribuer et chaque personne qui le fait nous rend plus forts. Ensemble, nous pouvons continuer à stimuler l'innovation sur le Web pour servir le bien commun. Cela commence ici, avec vous.

- -

Chaque partie de MDN (documents, démos et le site lui-même) est créée par une communauté ouverte de développeuses et développeurs. Rejoignez-nous !

- -

4 étapes simples vers MDN

- -

MDN est une ressource open source où toute personne peut ajouter et modifier des contenus. Il n'est pas nécessaire d'être un programmeur ou d'en savoir beaucoup sur les technologies. Il y a beaucoup de choses à faire, des plus simples (relecture et correction de fautes de frappe) aux plus complexes (rédaction de la documentation des API).

- -

Contribuer est facile et sûr. Même si vous faites une erreur, elle est facilement corrigée. Même si vous ne savez pas exactement comment les choses doivent être présentées, ou si votre grammaire n'est pas très bonne, ne vous inquiétez pas ! Nous avons une équipe de personnes dont le travail consiste à s'assurer que le contenu de MDN est aussi bon que possible. Quelqu'un sera là pour s'assurer que votre travail est soigné et bien écrit. Partagez ce que vous savez et suivez vos points forts.

- -

Étape 1 : Créer un compte GitHub

- -

Pour commencer vos contributions à MDN, vous devez créer un compte GitHub.

- - -

Étape 2 : Choisir une tâche à accomplir

- -

Maintenant que vous êtes connecté, lisez les descriptions des différents types de tâches disponibles sur la page relative aux contributions, et décidez de celle qui vous attire le plus. Vous pouvez choisir la tâche qui vous convient et commencer à contribuer.

- -

Étape 3 : Effectuer la tâche

- -

Une fois que vous avez décidé du type de tâche que vous voulez accomplir, trouvez une page spécifique, un exemple de code, etc. sur lequel travailler, et faites-le !

- -

Étape 4 : Demander de l'aide

- -

Si vous n'êtes pas sûr de ce que vous devez faire à un moment donné, vous pouvez demander de l'aide. Il existe plusieurs options d'aide :

- - - -

Ne vous souciez pas de le faire parfaitement ; d'autres contributeurs MDN sont là pour aider à corriger les erreurs qui se glissent.

- -

Guides complets et utiles pour les débutants

- -

Nous attendons des contributeurs à MDN qu'ils aient un certain nombre de connaissances préalables avant de commencer à travailler sur le contenu. Si les sujets suivants vous sont inconnus, nous vous conseillons de consulter les liens fournis pour vous aider à vous mettre à niveau :

- - diff --git a/files/fr/mdn/contribute/getting_started/index.md b/files/fr/mdn/contribute/getting_started/index.md new file mode 100644 index 0000000000..563a36e2d7 --- /dev/null +++ b/files/fr/mdn/contribute/getting_started/index.md @@ -0,0 +1,59 @@ +--- +title: Débuter sur MDN +slug: MDN/Contribute/Getting_started +tags: + - Documentation + - Getting Started + - Guide + - MDN + - MDN Project + - New Contributors +translation_of: MDN/Contribute/Getting_started +--- +
{{MDNSidebar}}
+ +

Nous sommes une communauté ouverte de développeuses et développeurs qui créent des ressources pour un meilleur Web, quelle que soit la marque, le navigateur ou la plate-forme. Tout le monde peut contribuer et chaque personne qui le fait nous rend plus forts. Ensemble, nous pouvons continuer à stimuler l'innovation sur le Web pour servir le bien commun. Cela commence ici, avec vous.

+ +

Chaque partie de MDN (documents, démos et le site lui-même) est créée par une communauté ouverte de développeuses et développeurs. Rejoignez-nous !

+ +

4 étapes simples vers MDN

+ +

MDN est une ressource open source où toute personne peut ajouter et modifier des contenus. Il n'est pas nécessaire d'être un programmeur ou d'en savoir beaucoup sur les technologies. Il y a beaucoup de choses à faire, des plus simples (relecture et correction de fautes de frappe) aux plus complexes (rédaction de la documentation des API).

+ +

Contribuer est facile et sûr. Même si vous faites une erreur, elle est facilement corrigée. Même si vous ne savez pas exactement comment les choses doivent être présentées, ou si votre grammaire n'est pas très bonne, ne vous inquiétez pas ! Nous avons une équipe de personnes dont le travail consiste à s'assurer que le contenu de MDN est aussi bon que possible. Quelqu'un sera là pour s'assurer que votre travail est soigné et bien écrit. Partagez ce que vous savez et suivez vos points forts.

+ +

Étape 1 : Créer un compte GitHub

+ +

Pour commencer vos contributions à MDN, vous devez créer un compte GitHub.

+ + +

Étape 2 : Choisir une tâche à accomplir

+ +

Maintenant que vous êtes connecté, lisez les descriptions des différents types de tâches disponibles sur la page relative aux contributions, et décidez de celle qui vous attire le plus. Vous pouvez choisir la tâche qui vous convient et commencer à contribuer.

+ +

Étape 3 : Effectuer la tâche

+ +

Une fois que vous avez décidé du type de tâche que vous voulez accomplir, trouvez une page spécifique, un exemple de code, etc. sur lequel travailler, et faites-le !

+ +

Étape 4 : Demander de l'aide

+ +

Si vous n'êtes pas sûr de ce que vous devez faire à un moment donné, vous pouvez demander de l'aide. Il existe plusieurs options d'aide :

+ + + +

Ne vous souciez pas de le faire parfaitement ; d'autres contributeurs MDN sont là pour aider à corriger les erreurs qui se glissent.

+ +

Guides complets et utiles pour les débutants

+ +

Nous attendons des contributeurs à MDN qu'ils aient un certain nombre de connaissances préalables avant de commencer à travailler sur le contenu. Si les sujets suivants vous sont inconnus, nous vous conseillons de consulter les liens fournis pour vous aider à vous mettre à niveau :

+ + diff --git a/files/fr/mdn/contribute/github_beginners/index.html b/files/fr/mdn/contribute/github_beginners/index.html deleted file mode 100644 index 96dff3ffa4..0000000000 --- a/files/fr/mdn/contribute/github_beginners/index.html +++ /dev/null @@ -1,438 +0,0 @@ ---- -title: GitHub pour les débutants -slug: MDN/Contribute/GitHub_beginners -tags: - - Best practices - - Community - - GitHub - - MDN - - Beginners -translation_of: MDN/Contribute/GitHub_beginners ---- -

{{MDNSidebar}}

- -

Git et GitHub sont des outils difficiles à apprendre et à maîtriser, mais avec quelques commandes simples et quelques bons conseils, vous devriez pouvoir en faire assez pour commencer à contribuer à MDN sans trop de difficultés. Le but de cet article n'est pas de vous aider à maîtriser Git ou GitHub, mais de vous donner juste assez d'éléments pour être productif à un niveau de base et contribuer à MDN.

- -

Si vous êtes déjà familiarisé avec les bases de Git/GitHub, vous n'apprendrez probablement rien de nouveau ici, mais cet article peut néanmoins vous être utile comme référence. Il existe également une antisèche GitHub disponible, avec juste les commandes et aucune des longues explications.

- -

Concepts essentiels

- -

Voici les concepts essentiels que vous devez connaître pour tirer le meilleur parti de Git et de GitHub.

- - - -

Hypothèses formulées par cet article

- -

Cet article part du principe que :

- - - -

Configuration initiale

- -

Avant de commencer à travailler sur un dépôt particulier, suivez ces étapes :

- -
    -
  1. Installez Git sur votre ordinateur. Allez sur la page de téléchargement de Git, téléchargez la dernière version pour votre ordinateur, et installez-la. Si vous êtes un utilisateur Windows, vous devriez également installer le paquet Git pour Windows, qui inclut Gitbash.
    2. -
  2. Pendant que vous y êtes, installez les autres dépendances requises pour travailler localement avec MDN - Node.js et yarn. -
      -
    1. Installez Node.js en suivant le lien ci-dessus et en téléchargeant et installant la dernière version pour votre ordinateur.
      2. -
    2. Une fois que vous avez installé Node.js, installez yarn en exécutant npm install --global yarn.
      3. -
    -
    3. -
  3. Créez un répertoire séparé quelque part sur votre ordinateur pour y stocker tous vos dépôts Git, qui soit facile à trouver et à atteindre en ligne de commande. Un répertoire appelé mdn-git à l'intérieur de votre répertoire home/user serait approprié.
    4. -
  4. Créez un compte GitHub si vous n'en avez pas déjà un. Vous aurez besoin d'un compte pour contribuer aux dépôts de MDN.
    5. -
- -

Configuration de l'authentification SSH sur GitHub

- -

À ce stade, vous devez configurer une clé SSH sur votre compte GitHub. Il s'agit essentiellement d'un mécanisme de sécurité qui vous identifie auprès de GitHub et vous évite de devoir vous authentifier à chaque fois que vous utilisez les services GitHub.

- -

GitHub a créé un guide utile pour configurer cela - voir le point de départ sur Connexion à GitHub avec SSH. Suivez chacune des étapes ici pour vous configurer avec SSH sur GitHub.

- -

Si vous ne le faites pas, vous pourrez toujours contribuer au MDN, mais vous devrez saisir votre nom d'utilisateur et votre mot de passe à chaque fois que vous interagirez avec GitHub (par exemple, lorsque vous soumettez une demande de triage, comme indiqué ci-dessous).

- -

Se préparer à travailler sur un dépôt spécifique

- - -
-

Note : pour la traduction française :

-

Ce qui a été expliqué par Chris Mills ici est identique pour le dépôt de traduction français, vous devez remplacer mdn/content par mdn/translated-content, et <votre-nom-utilisateur>/content par <votre-nom-utilisateur>/translated-content

-

Vous pouvez retrouver des explications de ceci sur notre article Comment contribuer sur GitHub au MDN

-
- - -

Il existe un certain nombre de dépôts différents que vous pouvez avoir à mettre à jour lorsque vous travaillez sur différentes tâches MDN (voir Où se trouve tout sur MDN ? Un guide de nos dépôts), mais il y a un certain nombre d'étapes de configuration que vous devriez suivre sur chaque dépôt sur lequel vous travaillez, pour rendre les choses plus faciles et plus cohérentes.

- -

Bifurcation et clonage

- -

La Bifurcation et le Clonage sont deux termes que vous rencontrerez souvent dans le monde de Git :

- - - -

Il est possible de faire les deux choses séparément, mais en pratique, vous les ferez presque toujours ensemble lorsque vous contribuerez aux projets d'autres personnes. Vous devez d'abord créer une bifurcation de chaque dépôt sur lequel vous souhaitez travailler. Cela est nécessaire pour soumettre des demandes de modification à la version principale du dépôt (nous verrons plus tard comment créer une demande de modification). Pour des raisons de sécurité, vous ne pouvez pas soumettre des modifications directement à la version principale du dépôt.

- -

Bifurquons le dépôt https://github.com/mdn/content dès maintenant ; vous contribuerez certainement à ce dépôt à un moment donné. Suivez les étapes suivantes :

- -
    -
  1. -

    Localisez le bouton « Fork » dans le coin supérieur droit de la page du dépôt de contenu, et appuyez dessus :

    -

    Bouton étiqueté fork, avec le numéro 609 à côté.

    -
    2. -
  2. -

    Une fenêtre de dialogue s'affiche, vous demandant où vous souhaitez transférer le dépôt. Sélectionnez votre compte GitHub personnel.

    -

    Un message apparaîtra disant quelque chose comme « Forking mdn/content. It should only take a few seconds. ». Une fois que GitHub a terminé la bifurcation, votre navigateur devrait vous rediriger vers la page du nouveau « fork ». À titre d'exemple, mon « fork » de https://github.com/mdn/content est disponible l'adresse https://github.com/chrisdavidmills/content.

    -
    3. -
- -

Maintenant que vous avez dupliqué le dépôt, il est temps de cloner votre copie localement. Pour ce faire :

- -
    -
  1. -

    Allez sur la page de votre bifurcation sur github.com (par exemple https://github.com/<votre-nom-utilisateur>/content).

    -
    2. -
  2. -

    Appuyez sur le bouton vert « Code » en haut de la liste des fichiers. Quelque chose de similaire à la fenêtre contextuelle suivante devrait apparaître :

    -

    Fenêtre contextuelle montrant une URL de clonage avec les options d'ouverture via le bureau GitHub et de téléchargement du zip.

    -
    3. -
  3. -

    Si vous avez configuré l'authentification SSH comme indiqué ci-dessus, cliquez sur l'onglet "SSH" et copiez l'URL git@github.com:<votre-nom-utilisateur>/content.git à partir du champ de texte de la fenêtre de dialogue. Si vous n'avez pas configuré l'authentification SSH, copiez plutôt l'URL depuis le champ de texte de l'onglet "HTTPS", qui devrait ressembler à ceci : https://github.com/<votre-nom-utilisateur>/content.git.

    -
    4. -
  4. -

    Maintenant, ouvrez votre console de commande sur votre ordinateur, et naviguez dans le répertoire que vous avez configuré plus tôt pour stocker les clones de votre dépôt git local à l'aide de la commande cd, par ex.

    - 
    cd git
    -
    5. -
  5. -

    Clonez votre bifurcation en entrant une commande de la forme suivante :

    - 
    git clone url-que-vous-avez-copié
    -

    Ainsi, par exemple, ma commande de clonage ressemblait à ceci :

    - 
    git clone git@github.com:chrisdavidmills/content.git
    -
    6. -
- -

Vous devriez maintenant trouver un répertoire de contenu dans votre répertoire git, contenant le contenu du dépôt.

- -

Configuration d'un suivi distant pour pointer vers la version principale du dépôt

- -

La dernière chose à faire avant de passer à autre chose, c'est de configurer un remote ou « suivi distant » pour pointer vers la version principale du dépôt, par exemple https://github.com/mdn/content dans le cas de notre exemple. Un suivi distant est essentiellement un pointeur vers un emplacement de dépôt distant spécifique sur GitHub, et est le plus souvent utilisé pour mettre à jour votre clone local afin qu'il soit à jour avec le dernier dépôt principal, comme nous le verrons ci-dessous.

- -

La configuration d'un suivi distant se fait avec la commande git remote add, qui ressemble à ceci :

- -
git remote add remote-name repo-you-want-to-point-to
- - - -

Donc, pour ajouter votre suivi :

- -
    -
  1. -

    Allez sur la page github.com de la version principale du dépôt (https://github.com/mdn/content dans cet exemple) et récupérez l'URL SSH ou HTTPS selon le cas, dans la fenêtre contextuelle « Code ».

    -
    2. -
  2. -

    Dans votre console de commande, utilisez cd pour aller dans votre répertoire de contenu :

    - 
    cd content
    -
    3. -
  3. -

    Exécutez maintenant une commande selon les lignes suivantes, en remplaçant remote-name et repo-you-want-to-point-to comme il convient :

    - 
    git remote add remote-name repo-you-want-to-point-to
    -

    Ainsi, par exemple, j'ai utilisé l'URL SSH et j'ai appelé mon suivi distant "mozilla" :

    - 
    git remote add mozilla git@github.com:mdn/content.git
    -
    4. -
- -

Votre suivi distant devrait maintenant être configuré. Vous pouvez le vérifier en exécutant la commande git remote -v dans votre terminal, qui sort une liste de vos noms de suivi distant et où ils pointent. Vous devriez voir quelque chose un peu comme ceci :

- -
mozilla    git@github.com:mdn/content.git (fetch)
-mozilla    git@github.com:mdn/content.git (push)
-origin    git@github.com:chrisdavidmills/content.git (fetch)
-origin    git@github.com:chrisdavidmills/content.git (push)
- -

Préparation d'une modification du dépôt.

- -

Maintenant que votre clone de fork local est prêt à fonctionner, il y a un ensemble de commandes que vous devez prendre l'habitude d'exécuter avant d'essayer d'effectuer de nouvelles modifications.

- -

Passer à la branche principale

- -

Chaque dépôt a un certain nombre de branches différentes, qui sont essentiellement des versions différentes du code de base dans le même dépôt. L'idée est que pour chaque modification apportée au code de base, vous effectuez la modification sur une branche séparée et la testez d'abord, avant de pousser les modifications vers la copie principale du code.

- -

La branche principale du dépôt de contenu est appelée « main » (elle peut être appelée autrement, comme « master » dans d'autres dépôts, et si c'est le cas, vous devrez mettre à jour son nom dans toutes les commandes présentées ci-dessous). Vous serez sur cette branche par défaut si vous venez de cloner le dépôt, mais si vous avez déjà effectué des modifications, vous serez probablement sur une autre branche.

- -

Assurez-vous d'exécuter la commande suivante pour passer à la branche principale avant de faire quoi que ce soit d'autre :

- -
git switch main
- -
-

Note : Dans d'autres tutoriels, vous avez peut-être vu git checkout utilisée pour changer de branche dans un dépôt. Cela fonctionne bien la plupart du temps, mais peut parfois avoir des effets secondaires involontaires, c'est pourquoi dans ce tutoriel nous recommandons la commande git switch, plus récente, qui est conçue pour changer de branche et a moins de chance de faire des erreurs. Si vous êtes intéressé par la façon dont ces commandes sont liées, et les différences entre elles, l'article Les points forts de Git 2.23 > Alternatives expérimentales pour git checkout fournit un bon résumé.

-
- -

Mettre à jour votre branche principale

- -

Ensuite, vous devez mettre à jour votre branche principale afin qu'elle contienne le même contenu que la branche principale du dépôt principal. Le dépôt de contenu est mis à jour plusieurs fois par jour par un grand nombre de contributeurs, donc si vous ne le faites pas, votre version ne sera plus à jour, ce qui posera des problèmes lorsque vous essaierez de soumettre vos mises à jour. C'est là que votre suivi distant vous sera utile !

- -

Pour mettre à jour votre dépôt :

- -
    -
  1. -

    Tout d'abord, récupérez le contenu mis à jour de votre suivi distant avec la commande suivante :

    - 
    git fetch remote-name
    -

    Par exemple :

    - 
    git fetch mozilla
    -
    2. -
  2. -

    Ensuite, remplacez le contenu de votre branche principale par la branche principale du dépôt distant. Il existe de nombreuses façons différentes de le faire, mais j'ai tendance à utiliser la commande rebase, comme ceci :

    - 
    git rebase remote-name/main-branch-name
    -

    Par exemple :

    - 

    git rebase mozilla/main
    -
    3. -
  3. -

    Enfin, poussez ces changements vers la version distante de votre bifircation en utilisant :

    - 
    git push
    -
    4. -
- -

Vous saurez si vos mises à jour ont fonctionné correctement en regardant la page github.com de votre fork (c-à-d. que la mienne est https://github.com/chrisdavidmills/content). Elle devrait dire quelque chose comme « This branch is even with mdn:main. » quelque part près du haut de page. Si cela dit que votre branche principale est derrière mdn:main par un certain nombre de commits, alors vous devrez essayer à nouveau, ou regarder la section dépannage.

- -

Créez une nouvelle branche pour y faire vos modifications

- -

Une fois que vous avez mis à jour votre branche principale dans votre bifurcation, vous devez toujours créer une nouvelle branche pour y apporter une modification. Vous ne devriez jamais faire vos modifications dans la branche principale et le soumettre à partir de là - cela peut devenir très vite désordonné, croyez-nous. Il est beaucoup plus propre et moins sujet aux erreurs de faire tout le travail dans des branches séparées.

- -

Pour créer une nouvelle branche :

- -
    -
  1. -

    Allez sur la page de votre bifurcation sur github.com (la mienne est à l'adresse https://github.com/chrisdavidmills/content) et trouvez le bouton de branche en haut à gauche de la liste des fichiers, qui devrait indiquer « main » :

    -

    Bouton intitulé main

    -
    2. -
  2. -

    Cliquez dessus, et vous verrez apparaître une liste de branches et un champ de texte indiquant « Find or create a branch… » :

    -

    menu montrant une liste de noms de branches avec une zone de texte étiquetée trouver ou créer une branche

    -
    3. -
  3. -

    Si vous saisissez une partie du nom d'une branche existante dans le champ de texte, la liste des branches sera filtrée en fonction de cette chaîne de caractères, ce qui vous permettra de rechercher facilement des branches existantes. Cependant, nous voulons créer une nouvelle branche. Entrez un nom de branche qui n'existe pas encore (essayez quelque chose comme test-branch) et l'affichage changera pour vous donner un bouton intitulé « Create branch : test-branch from 'main' » :

    -

    menu montrant un nouveau nom de branche, test-branch, entré dans une zone de texte, avec un bouton de création de branche en dessous

    -
    4. -
  4. -

    Une fois que vous êtes satisfait du nom de votre branche, cliquez sur ce bouton, et l'affichage sera mis à jour pour montrer le nom de la branche dans le bouton branche :

    -

    Bouton intitulé test-branch

    -
    5. -
- -

Voilà, c'est fait ! Vous avez maintenant créé une nouvelle branche dans laquelle vous allez travailler. Cette branche est identique à l'état de la branche principale au moment où vous l'avez créée. C'est un bon point de départ pour notre travail.

- -

Conseils :

- - - -

Obtenez votre branche localement et passez dessus

- -

La section précédente vous a appris à créer une nouvelle branche dans votre bifurcation, mais elle n'existe actuellement que dans votre version distante du dépôt. Pour travailler dessus, vous devez la placer dans votre version locale.

- -

Pour ce faire, retournez dans votre terminal et, en vous assurant que vous êtes à l'intérieur du répertoire du dépôt sur lequel vous travaillez (content pour cet exemple) :

- -
    -
  1. Tirez les changements distants vers votre clone local en exécutant la commande git pull.
    2. -
  2. Vous devriez obtenir un message du type * [new branch] test-branch -> origin/test-branch.
    3. -
  3. Pour passer à votre branche (c'est-à-dire passer de « main », pour travailler dans cette branche à la place), exécutez la commande git switch test-branch.
    4. -
- -

Si vous avez réussi, git devrait vous dire quelque chose comme ceci :

- -
Branch 'test-branch' set up to track remote branch 'test-branch' from 'origin'.
-Switched to a new branch 'test-branch'
- -

Notez que vous pouvez vérifier le statut de votre dépôt, y compris la branche sur laquelle vous vous trouvez, à tout moment en exécutant la commande git status. Essayez maintenant, et git devrait vous dire quelque chose comme ceci :

- -
On branch test-branch
-Your branch is up to date with 'origin/test-branch'.
-
-nothing to commit, working tree clean
- -

Cela semble correct. Nous sommes sur la branche "test-branch", et nous n'avons pas encore fait de changements.

- -

Ajouter, valider et pousser les changements

- -

À ce stade, vous êtes prêt à apporter des modifications au dépôt sur lequel vous travaillez, pour corriger un bogue sur lu MDN ou autre. Nous allons sauter cette partie, car ce n'est pas le but de ce tutoriel. Si vous voulez corriger un vrai problème sur le MDN, allez choisir un bogue à corriger dans notre liste des problèmes de contenu, ou lisez Contribuer à MDN pour plus de conseils.

- -

Si vous voulez simplement suivre ce tutoriel à titre d'exemple, faisons quelque chose de simple.

- -
    -
  1. -

    Allez dans le fichier content/README.md, et ajoutez une seule lettre dans le titre supérieur du README.

    -
    2. -
  2. -

    Maintenant, retournez à votre ligne de commande et entrez à nouveau la commande git status. Cette fois-ci, git devrait vous dire quelque chose comme ceci :

    - 
    Your branch is up to date with 'origin/test-branch'.
-
-    Changes not staged for commit:
-      (use "git add <file>..." to update what will be committed)
-      (use "git restore <file>..." to discard changes in working directory)
-        modified:   README.md
-
-    no changes added to commit (use "git add" and/or "git commit -a")
    -
    3. -
  3. -

    À ce stade, il vous indique donc les fichiers que vous avez modifiés. L'étape suivante consiste à les "ajouter", c'est-à-dire à les ajouter à une liste de fichiers que vous souhaitez commiter pour les pousser vers le fork distant. Pour ajouter ce fichier à la liste de commit, tapez ce qui suit :

    - 
    git add README.md
    -
    -

    Note : README.md est le chemin d'accès au fichier que vous avez modifié, pas seulement son nom. S'il était à l'intérieur d'un sous-répertoire, vous auriez dû écrire le chemin complet du fichier.

    -
    -
    4. -
  4. -

    Si vous exécutez git status à nouveau, vous verrez maintenant ceci :

    - 
    On branch test-branch
-    Your branch is up to date with 'origin/test-branch'.
-
-    Changes to be committed:
-      (use "git restore --staged <file>..." to unstage)
-        modified:   README.md
    -
    5. -
  5. -

    Git nous dit que README.md est maintenant dans notre liste de commit. Pour inclure tous les fichiers de la liste de commit dans un commit (un seul ensemble de changements que nous essaierons plus tard d'envoyer à la branche principale), entrez ce qui suit (l'option -m est l'abréviation de « message ») :

    - 
    git commit -m 'my first commit'
    -

    Git vous dira ceci :

    - 
    [test-branch 44b207ef6] my first commit
-     1 file changed, 1 insertion(+), 1 deletion(-)
    -

    Pour montrer qu'il a enregistré que vous avez fait un commit.

    -
    6. -
  6. -

    Exécutez git status à nouveau, et vous obtiendrez cette information :

    - 
    On branch test-branch
-    Your branch is ahead of 'origin/test-branch' by 1 commit.
-      (use "git push" to publish your local commits)
-
-    nothing to commit, working tree clean
    -
    7. -
- -

La lecture de l'information a fondamentalement été réinitialisée - elle nous dit qu'il n'y a pas de changements à soumettre, parce que nous avons maintenant envoyé notre changement précédent dans le système comme un commit. La principale différence par rapport à la version précédente est la ligne "Votre branche est en avance sur 'origin/test-branch' de 1 commit". - notre version locale de la branche "test-branch" est maintenant en avance sur la version distante de "test-branch" d'un commit - en d'autres termes, nous avons fait un changement localement que la branche distante n'a pas.

- -

Envoyons notre changement local à la branche distante. Vous pouvez le faire en exécutant la commande git push - essayez maintenant. S'il n'y a pas d'erreurs, vous devriez obtenir un affichage comme celui-ci :

- -
Enumerating objects: 5, done.
-Counting objects: 100% (5/5), done.
-Delta compression using up to 8 threads
-Compressing objects: 100% (3/3), done.
-Writing objects: 100% (3/3), 292 bytes | 292.00 KiB/s, done.
-Total 3 (delta 2), reused 0 (delta 0)
-remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
-To github.com:chrisdavidmills/content.git
-    77215e31e..44b207ef6  test-branch -> test-branch
- -

Création d'une demande de triage

- -

À ce stade, retournez sur la page github.com de votre dépôt distant. Vous devriez voir un message du type « This branch is 1 commit ahead of mdn:main. ». Ce qui signifie que le contenu de notre bifurcation contient un changement de contenu (commit) que la branche « main » de Mozilla ne contient pas.

- -
    -
  1. -

    Pour envoyer notre modification vers la copie principale du dépôt, nous devons créer une demande de modification. Cela peut être fait facilement en utilisant le bouton "Compare & pull request" que vous devriez voir en haut de la liste des fichiers, une fois que la branche a eu une modification poussée vers elle.

    - -

    bannière avec le texte test-branch had recent pushes, et un bouton intitulé compare and pull request

    - -

    Appuyez sur ce bouton, et vous devriez obtenir un nouvel écran qui s'affiche comme suit :

    - -

    un formulaire de demande de triage ouvert, qui comprend des champs de texte pour le titre et la description

    - -
    -

    Attention : Ne suivez le reste de ces étapes que si vous avez une réelle modification à apporter au dépôt ! Veuillez ne pas soumettre de PR de test à nos dépôts.

    -
    -
    2. -
  2. -

    À ce stade, entrez un titre et une description utiles pour votre PR, en disant exactement ce qu'il a changé, pourquoi c'est une bonne chose, et quel problème connexe il a corrigé, le cas échéant. Plus précisément, incluez une ligne disant Fixes issue-url. GitHub rend automatiquement cela comme un lien vers le numéro de problème, par exemple Fixes #1234 et, en outre, ferme automatiquement le problème connexe une fois que la pull request est fusionnée.

    -
    3. -
  3. -

    Une fois que vous êtes prêt à envoyer votre pull request, cliquez sur le bouton « Create pull request ». Votre pull request (PR) apparaîtra alors dans la liste « Pull requests » du dépôt, où elle sera examinée par nos équipes de révision et, si possible, fusionnée dans le code principal.

    -

    Si l'équipe de révision souhaite que vous apportiez des modifications, elle vous en informera dans les commentaires du fil de discussion de la demande de triage (vous devriez recevoir une notification par courriel pour vous en informer).

    -
    4. -
  4. -

    Si vous souhaitez apporter d'autres modifications à la même demande de dépôt que vous avez déjà soumise, vous pouvez le faire en faisant d'autres commits sur la même branche locale et en les poussant ensuite comme expliqué précédemment. Il n'est pas nécessaire de créer une demande de pull complètement nouvelle. Veuillez simplement vous assurer que vous les faites sur la même branche que précédemment.

    -
    5. -
- -

Dépannage

- -

Le tutoriel ci-dessus vise à vous fournir les bases de Git et de GitHub dont vous aurez besoin pour contribuer aux dépôts GitHub à un niveau de base. Nous espérons qu'il vous a été utile ! Nous aimerions également aborder le fait que, bien qu'étant le système de contrôle de version standard de l'industrie du web, Git a une sorte de réputation mythique/légendaire d'outil péniblement difficile à apprendre et à utiliser.

- -

Nous ne sommes pas sûrs que ce soit tout à fait juste. Git comporte de nombreuses commandes qui sont parfois assez cryptiques dans leur utilisation, et il faut beaucoup de temps pour les maîtriser. Il est également juste de dire que si vous oubliez certaines commandes ou que vous faites les choses dans le mauvais ordre, vous pouvez vous retrouver dans un désordre intéressant dont il est difficile de se sortir. Toutefois, si vous prenez les bonnes habitudes décrites ci-dessus, vous ne devriez pas trop vous tromper. Il convient également de mentionner que Git est beaucoup plus facile à utiliser qu'il y a dix ans.

- -

Cette section sera complétée au fil du temps et comprendra des commandes/séquences utiles pour vous aider à résoudre les problèmes courants.

- -

Annulation d'une modification que vous avez apportée à un fichier que vous n'avez pas encore ajouté à la liste des commits.

- -

Si vous avez modifié un fichier, mais que vous n'avez pas encore exécuté la commande git add file-path pour l'ajouter à la liste des commits, vous pouvez revenir à l'état dans lequel il était lorsque vous avez extrait la branche pour la première fois en exécutant :

- -
git restore file-path
- -

Suppression d'un fichier de la liste de commit

- -

Si vous avez déjà exécuté la commande git add file-path pour ajouter un fichier à la liste de commit, mais que vous voulez maintenant le supprimer de la liste de commit, vous pouvez utiliser la commande :

- -
git restore --staged file-path
- -

Annuler un commit

- -

Si vous avez soumis la liste de commit en utilisant git commit -m 'mon message de commit', et que vous ne l'avez pas encore poussé, mais que vous vous êtes maintenant rendu compte que vous avez mis quelque chose dedans que vous voulez enlever, vous pouvez inverser votre commit local en utilisant :

- -
git reset HEAD~1
- -

Cela vous ramènera à l'état où les changements de ce commit ne sont pas encore ajoutés à la liste des commits (vous devrez les ajouter à nouveau dans git après avoir résolu le problème). Notez que cela vous ramène à l'état avant que vous ne commitiez quoi que ce soit dans cette session. Cela ne vous aidera pas si vous avez besoin de faire quelque chose de plus complexe, comme revenir sur le commit du milieu d'un ensemble de trois. Nous en resterons là pour cette leçon.

- -

Inverser un commit qui a été poussé vers la bifurcation distante

- -

À ce stade, il n'est pas vraiment possible de revenir en arrière, ou de rembobiner. Au lieu de cela, vous devez pousser un autre commit pour inverser les effets de celui dont vous voulez vous débarrasser. Vous pourriez le faire manuellement en utilisant certains des outils que nous vous avons déjà donnés ci-dessus, mais il y a une commande intégrée qui rend cela plus facile - git revert. Cela peut être utilisé pour créer automatiquement un commit qui rétablit les changements au point que vous spécifiez.

- -
    -
  1. -

    Dans sa forme la plus simple, vous pouvez exécuter la commande suivante pour créer un commit qui ramènera votre branche distante à l'état dans lequel vous étiez avant de commencer à soumettre le commit :

    - 
    git revert HEAD
    -
    2. -
  2. -

    Cela aura pour conséquence l'ouverture d'un fichier de message de commit dans votre éditeur de texte par défaut que vous devrez vérifier pour vous assurer que vous êtes satisfait. Fermez-le, et git finalisera la création du commit.

    -
    3. -
  3. -

    Maintenant, il faut juste le pousser :

    - 
    git push
    -
    4. -
- -

Si vous regardez à nouveau la page github.com de votre bifurcation distante, vous verrez le commit que vous vouliez inverser, plus le commit qui l'inverse.

- -
-

Note : Une autre façon de se débarrasser de fichiers qui se sont retrouvés dans des demandes de triage que vous ne voulez pas voir figurer est d'utiliser l'interface utilisateur de GitHub. Allez sur la page de votre demande sur github.com, allez dans l'onglet « Files changed », et trouvez le fichier que vous voulez supprimer de la demande. En haut à droite de la boîte du fichier dans la page, il y aura un menu à « trois points » (...). Appuyez sur ce bouton et choisissez « Delete file ». Dans la page de confirmation, entrez un titre pour le nouveau commit, assurez-vous que la case « Commit directly... « est cochée, et appuyez sur le bouton « Commit changes ».

-

C'est généralement une bonne idée de faire en sorte que le reste de la demande de trisage ressemble exactement à ce que vous voulez avant de faire des changements via l'interface utilisateur de GitHub. Si vous faites quelque chose comme ça et que vous devez ensuite faire d'autres changements, vous devrez vous rappeler de tirer les changements que vous avez faits sur votre branche distante vers votre branche locale (par exemple avec git pull) avant de pouvoir pousser d'autres commits.

-
- -

Vous voulez en voir plus ?

- -

Si vous pensez que ce guide de dépannage devrait contenir plus d'informations, veuillez créer un ticket pour suggérer ce que vous pensez que nous devrions inclure.

- -

Voir aussi

- - diff --git a/files/fr/mdn/contribute/github_beginners/index.md b/files/fr/mdn/contribute/github_beginners/index.md new file mode 100644 index 0000000000..96dff3ffa4 --- /dev/null +++ b/files/fr/mdn/contribute/github_beginners/index.md @@ -0,0 +1,438 @@ +--- +title: GitHub pour les débutants +slug: MDN/Contribute/GitHub_beginners +tags: + - Best practices + - Community + - GitHub + - MDN + - Beginners +translation_of: MDN/Contribute/GitHub_beginners +--- +

{{MDNSidebar}}

+ +

Git et GitHub sont des outils difficiles à apprendre et à maîtriser, mais avec quelques commandes simples et quelques bons conseils, vous devriez pouvoir en faire assez pour commencer à contribuer à MDN sans trop de difficultés. Le but de cet article n'est pas de vous aider à maîtriser Git ou GitHub, mais de vous donner juste assez d'éléments pour être productif à un niveau de base et contribuer à MDN.

+ +

Si vous êtes déjà familiarisé avec les bases de Git/GitHub, vous n'apprendrez probablement rien de nouveau ici, mais cet article peut néanmoins vous être utile comme référence. Il existe également une antisèche GitHub disponible, avec juste les commandes et aucune des longues explications.

+ +

Concepts essentiels

+ +

Voici les concepts essentiels que vous devez connaître pour tirer le meilleur parti de Git et de GitHub.

+ + + +

Hypothèses formulées par cet article

+ +

Cet article part du principe que :

+ + + +

Configuration initiale

+ +

Avant de commencer à travailler sur un dépôt particulier, suivez ces étapes :

+ +
    +
  1. Installez Git sur votre ordinateur. Allez sur la page de téléchargement de Git, téléchargez la dernière version pour votre ordinateur, et installez-la. Si vous êtes un utilisateur Windows, vous devriez également installer le paquet Git pour Windows, qui inclut Gitbash.
    2. +
  2. Pendant que vous y êtes, installez les autres dépendances requises pour travailler localement avec MDN - Node.js et yarn. +
      +
    1. Installez Node.js en suivant le lien ci-dessus et en téléchargeant et installant la dernière version pour votre ordinateur.
      2. +
    2. Une fois que vous avez installé Node.js, installez yarn en exécutant npm install --global yarn.
      3. +
    +
    3. +
  3. Créez un répertoire séparé quelque part sur votre ordinateur pour y stocker tous vos dépôts Git, qui soit facile à trouver et à atteindre en ligne de commande. Un répertoire appelé mdn-git à l'intérieur de votre répertoire home/user serait approprié.
    4. +
  4. Créez un compte GitHub si vous n'en avez pas déjà un. Vous aurez besoin d'un compte pour contribuer aux dépôts de MDN.
    5. +
+ +

Configuration de l'authentification SSH sur GitHub

+ +

À ce stade, vous devez configurer une clé SSH sur votre compte GitHub. Il s'agit essentiellement d'un mécanisme de sécurité qui vous identifie auprès de GitHub et vous évite de devoir vous authentifier à chaque fois que vous utilisez les services GitHub.

+ +

GitHub a créé un guide utile pour configurer cela - voir le point de départ sur Connexion à GitHub avec SSH. Suivez chacune des étapes ici pour vous configurer avec SSH sur GitHub.

+ +

Si vous ne le faites pas, vous pourrez toujours contribuer au MDN, mais vous devrez saisir votre nom d'utilisateur et votre mot de passe à chaque fois que vous interagirez avec GitHub (par exemple, lorsque vous soumettez une demande de triage, comme indiqué ci-dessous).

+ +

Se préparer à travailler sur un dépôt spécifique

+ + +
+

Note : pour la traduction française :

+

Ce qui a été expliqué par Chris Mills ici est identique pour le dépôt de traduction français, vous devez remplacer mdn/content par mdn/translated-content, et <votre-nom-utilisateur>/content par <votre-nom-utilisateur>/translated-content

+

Vous pouvez retrouver des explications de ceci sur notre article Comment contribuer sur GitHub au MDN

+
+ + +

Il existe un certain nombre de dépôts différents que vous pouvez avoir à mettre à jour lorsque vous travaillez sur différentes tâches MDN (voir Où se trouve tout sur MDN ? Un guide de nos dépôts), mais il y a un certain nombre d'étapes de configuration que vous devriez suivre sur chaque dépôt sur lequel vous travaillez, pour rendre les choses plus faciles et plus cohérentes.

+ +

Bifurcation et clonage

+ +

La Bifurcation et le Clonage sont deux termes que vous rencontrerez souvent dans le monde de Git :

+ + + +

Il est possible de faire les deux choses séparément, mais en pratique, vous les ferez presque toujours ensemble lorsque vous contribuerez aux projets d'autres personnes. Vous devez d'abord créer une bifurcation de chaque dépôt sur lequel vous souhaitez travailler. Cela est nécessaire pour soumettre des demandes de modification à la version principale du dépôt (nous verrons plus tard comment créer une demande de modification). Pour des raisons de sécurité, vous ne pouvez pas soumettre des modifications directement à la version principale du dépôt.

+ +

Bifurquons le dépôt https://github.com/mdn/content dès maintenant ; vous contribuerez certainement à ce dépôt à un moment donné. Suivez les étapes suivantes :

+ +
    +
  1. +

    Localisez le bouton « Fork » dans le coin supérieur droit de la page du dépôt de contenu, et appuyez dessus :

    +

    Bouton étiqueté fork, avec le numéro 609 à côté.

    +
    2. +
  2. +

    Une fenêtre de dialogue s'affiche, vous demandant où vous souhaitez transférer le dépôt. Sélectionnez votre compte GitHub personnel.

    +

    Un message apparaîtra disant quelque chose comme « Forking mdn/content. It should only take a few seconds. ». Une fois que GitHub a terminé la bifurcation, votre navigateur devrait vous rediriger vers la page du nouveau « fork ». À titre d'exemple, mon « fork » de https://github.com/mdn/content est disponible l'adresse https://github.com/chrisdavidmills/content.

    +
    3. +
+ +

Maintenant que vous avez dupliqué le dépôt, il est temps de cloner votre copie localement. Pour ce faire :

+ +
    +
  1. +

    Allez sur la page de votre bifurcation sur github.com (par exemple https://github.com/<votre-nom-utilisateur>/content).

    +
    2. +
  2. +

    Appuyez sur le bouton vert « Code » en haut de la liste des fichiers. Quelque chose de similaire à la fenêtre contextuelle suivante devrait apparaître :

    +

    Fenêtre contextuelle montrant une URL de clonage avec les options d'ouverture via le bureau GitHub et de téléchargement du zip.

    +
    3. +
  3. +

    Si vous avez configuré l'authentification SSH comme indiqué ci-dessus, cliquez sur l'onglet "SSH" et copiez l'URL git@github.com:<votre-nom-utilisateur>/content.git à partir du champ de texte de la fenêtre de dialogue. Si vous n'avez pas configuré l'authentification SSH, copiez plutôt l'URL depuis le champ de texte de l'onglet "HTTPS", qui devrait ressembler à ceci : https://github.com/<votre-nom-utilisateur>/content.git.

    +
    4. +
  4. +

    Maintenant, ouvrez votre console de commande sur votre ordinateur, et naviguez dans le répertoire que vous avez configuré plus tôt pour stocker les clones de votre dépôt git local à l'aide de la commande cd, par ex.

    + 
    cd git
    +
    5. +
  5. +

    Clonez votre bifurcation en entrant une commande de la forme suivante :

    + 
    git clone url-que-vous-avez-copié
    +

    Ainsi, par exemple, ma commande de clonage ressemblait à ceci :

    + 
    git clone git@github.com:chrisdavidmills/content.git
    +
    6. +
+ +

Vous devriez maintenant trouver un répertoire de contenu dans votre répertoire git, contenant le contenu du dépôt.

+ +

Configuration d'un suivi distant pour pointer vers la version principale du dépôt

+ +

La dernière chose à faire avant de passer à autre chose, c'est de configurer un remote ou « suivi distant » pour pointer vers la version principale du dépôt, par exemple https://github.com/mdn/content dans le cas de notre exemple. Un suivi distant est essentiellement un pointeur vers un emplacement de dépôt distant spécifique sur GitHub, et est le plus souvent utilisé pour mettre à jour votre clone local afin qu'il soit à jour avec le dernier dépôt principal, comme nous le verrons ci-dessous.

+ +

La configuration d'un suivi distant se fait avec la commande git remote add, qui ressemble à ceci :

+ +
git remote add remote-name repo-you-want-to-point-to
+ + + +

Donc, pour ajouter votre suivi :

+ +
    +
  1. +

    Allez sur la page github.com de la version principale du dépôt (https://github.com/mdn/content dans cet exemple) et récupérez l'URL SSH ou HTTPS selon le cas, dans la fenêtre contextuelle « Code ».

    +
    2. +
  2. +

    Dans votre console de commande, utilisez cd pour aller dans votre répertoire de contenu :

    + 
    cd content
    +
    3. +
  3. +

    Exécutez maintenant une commande selon les lignes suivantes, en remplaçant remote-name et repo-you-want-to-point-to comme il convient :

    + 
    git remote add remote-name repo-you-want-to-point-to
    +

    Ainsi, par exemple, j'ai utilisé l'URL SSH et j'ai appelé mon suivi distant "mozilla" :

    + 
    git remote add mozilla git@github.com:mdn/content.git
    +
    4. +
+ +

Votre suivi distant devrait maintenant être configuré. Vous pouvez le vérifier en exécutant la commande git remote -v dans votre terminal, qui sort une liste de vos noms de suivi distant et où ils pointent. Vous devriez voir quelque chose un peu comme ceci :

+ +
mozilla    git@github.com:mdn/content.git (fetch)
+mozilla    git@github.com:mdn/content.git (push)
+origin    git@github.com:chrisdavidmills/content.git (fetch)
+origin    git@github.com:chrisdavidmills/content.git (push)
+ +

Préparation d'une modification du dépôt.

+ +

Maintenant que votre clone de fork local est prêt à fonctionner, il y a un ensemble de commandes que vous devez prendre l'habitude d'exécuter avant d'essayer d'effectuer de nouvelles modifications.

+ +

Passer à la branche principale

+ +

Chaque dépôt a un certain nombre de branches différentes, qui sont essentiellement des versions différentes du code de base dans le même dépôt. L'idée est que pour chaque modification apportée au code de base, vous effectuez la modification sur une branche séparée et la testez d'abord, avant de pousser les modifications vers la copie principale du code.

+ +

La branche principale du dépôt de contenu est appelée « main » (elle peut être appelée autrement, comme « master » dans d'autres dépôts, et si c'est le cas, vous devrez mettre à jour son nom dans toutes les commandes présentées ci-dessous). Vous serez sur cette branche par défaut si vous venez de cloner le dépôt, mais si vous avez déjà effectué des modifications, vous serez probablement sur une autre branche.

+ +

Assurez-vous d'exécuter la commande suivante pour passer à la branche principale avant de faire quoi que ce soit d'autre :

+ +
git switch main
+ +
+

Note : Dans d'autres tutoriels, vous avez peut-être vu git checkout utilisée pour changer de branche dans un dépôt. Cela fonctionne bien la plupart du temps, mais peut parfois avoir des effets secondaires involontaires, c'est pourquoi dans ce tutoriel nous recommandons la commande git switch, plus récente, qui est conçue pour changer de branche et a moins de chance de faire des erreurs. Si vous êtes intéressé par la façon dont ces commandes sont liées, et les différences entre elles, l'article Les points forts de Git 2.23 > Alternatives expérimentales pour git checkout fournit un bon résumé.

+
+ +

Mettre à jour votre branche principale

+ +

Ensuite, vous devez mettre à jour votre branche principale afin qu'elle contienne le même contenu que la branche principale du dépôt principal. Le dépôt de contenu est mis à jour plusieurs fois par jour par un grand nombre de contributeurs, donc si vous ne le faites pas, votre version ne sera plus à jour, ce qui posera des problèmes lorsque vous essaierez de soumettre vos mises à jour. C'est là que votre suivi distant vous sera utile !

+ +

Pour mettre à jour votre dépôt :

+ +
    +
  1. +

    Tout d'abord, récupérez le contenu mis à jour de votre suivi distant avec la commande suivante :

    + 
    git fetch remote-name
    +

    Par exemple :

    + 
    git fetch mozilla
    +
    2. +
  2. +

    Ensuite, remplacez le contenu de votre branche principale par la branche principale du dépôt distant. Il existe de nombreuses façons différentes de le faire, mais j'ai tendance à utiliser la commande rebase, comme ceci :

    + 
    git rebase remote-name/main-branch-name
    +

    Par exemple :

    + 

    git rebase mozilla/main
    +
    3. +
  3. +

    Enfin, poussez ces changements vers la version distante de votre bifircation en utilisant :

    + 
    git push
    +
    4. +
+ +

Vous saurez si vos mises à jour ont fonctionné correctement en regardant la page github.com de votre fork (c-à-d. que la mienne est https://github.com/chrisdavidmills/content). Elle devrait dire quelque chose comme « This branch is even with mdn:main. » quelque part près du haut de page. Si cela dit que votre branche principale est derrière mdn:main par un certain nombre de commits, alors vous devrez essayer à nouveau, ou regarder la section dépannage.

+ +

Créez une nouvelle branche pour y faire vos modifications

+ +

Une fois que vous avez mis à jour votre branche principale dans votre bifurcation, vous devez toujours créer une nouvelle branche pour y apporter une modification. Vous ne devriez jamais faire vos modifications dans la branche principale et le soumettre à partir de là - cela peut devenir très vite désordonné, croyez-nous. Il est beaucoup plus propre et moins sujet aux erreurs de faire tout le travail dans des branches séparées.

+ +

Pour créer une nouvelle branche :

+ +
    +
  1. +

    Allez sur la page de votre bifurcation sur github.com (la mienne est à l'adresse https://github.com/chrisdavidmills/content) et trouvez le bouton de branche en haut à gauche de la liste des fichiers, qui devrait indiquer « main » :

    +

    Bouton intitulé main

    +
    2. +
  2. +

    Cliquez dessus, et vous verrez apparaître une liste de branches et un champ de texte indiquant « Find or create a branch… » :

    +

    menu montrant une liste de noms de branches avec une zone de texte étiquetée trouver ou créer une branche

    +
    3. +
  3. +

    Si vous saisissez une partie du nom d'une branche existante dans le champ de texte, la liste des branches sera filtrée en fonction de cette chaîne de caractères, ce qui vous permettra de rechercher facilement des branches existantes. Cependant, nous voulons créer une nouvelle branche. Entrez un nom de branche qui n'existe pas encore (essayez quelque chose comme test-branch) et l'affichage changera pour vous donner un bouton intitulé « Create branch : test-branch from 'main' » :

    +

    menu montrant un nouveau nom de branche, test-branch, entré dans une zone de texte, avec un bouton de création de branche en dessous

    +
    4. +
  4. +

    Une fois que vous êtes satisfait du nom de votre branche, cliquez sur ce bouton, et l'affichage sera mis à jour pour montrer le nom de la branche dans le bouton branche :

    +

    Bouton intitulé test-branch

    +
    5. +
+ +

Voilà, c'est fait ! Vous avez maintenant créé une nouvelle branche dans laquelle vous allez travailler. Cette branche est identique à l'état de la branche principale au moment où vous l'avez créée. C'est un bon point de départ pour notre travail.

+ +

Conseils :

+ + + +

Obtenez votre branche localement et passez dessus

+ +

La section précédente vous a appris à créer une nouvelle branche dans votre bifurcation, mais elle n'existe actuellement que dans votre version distante du dépôt. Pour travailler dessus, vous devez la placer dans votre version locale.

+ +

Pour ce faire, retournez dans votre terminal et, en vous assurant que vous êtes à l'intérieur du répertoire du dépôt sur lequel vous travaillez (content pour cet exemple) :

+ +
    +
  1. Tirez les changements distants vers votre clone local en exécutant la commande git pull.
    2. +
  2. Vous devriez obtenir un message du type * [new branch] test-branch -> origin/test-branch.
    3. +
  3. Pour passer à votre branche (c'est-à-dire passer de « main », pour travailler dans cette branche à la place), exécutez la commande git switch test-branch.
    4. +
+ +

Si vous avez réussi, git devrait vous dire quelque chose comme ceci :

+ +
Branch 'test-branch' set up to track remote branch 'test-branch' from 'origin'.
+Switched to a new branch 'test-branch'
+ +

Notez que vous pouvez vérifier le statut de votre dépôt, y compris la branche sur laquelle vous vous trouvez, à tout moment en exécutant la commande git status. Essayez maintenant, et git devrait vous dire quelque chose comme ceci :

+ +
On branch test-branch
+Your branch is up to date with 'origin/test-branch'.
+
+nothing to commit, working tree clean
+ +

Cela semble correct. Nous sommes sur la branche "test-branch", et nous n'avons pas encore fait de changements.

+ +

Ajouter, valider et pousser les changements

+ +

À ce stade, vous êtes prêt à apporter des modifications au dépôt sur lequel vous travaillez, pour corriger un bogue sur lu MDN ou autre. Nous allons sauter cette partie, car ce n'est pas le but de ce tutoriel. Si vous voulez corriger un vrai problème sur le MDN, allez choisir un bogue à corriger dans notre liste des problèmes de contenu, ou lisez Contribuer à MDN pour plus de conseils.

+ +

Si vous voulez simplement suivre ce tutoriel à titre d'exemple, faisons quelque chose de simple.

+ +
    +
  1. +

    Allez dans le fichier content/README.md, et ajoutez une seule lettre dans le titre supérieur du README.

    +
    2. +
  2. +

    Maintenant, retournez à votre ligne de commande et entrez à nouveau la commande git status. Cette fois-ci, git devrait vous dire quelque chose comme ceci :

    + 
    Your branch is up to date with 'origin/test-branch'.
+
+    Changes not staged for commit:
+      (use "git add <file>..." to update what will be committed)
+      (use "git restore <file>..." to discard changes in working directory)
+        modified:   README.md
+
+    no changes added to commit (use "git add" and/or "git commit -a")
    +
    3. +
  3. +

    À ce stade, il vous indique donc les fichiers que vous avez modifiés. L'étape suivante consiste à les "ajouter", c'est-à-dire à les ajouter à une liste de fichiers que vous souhaitez commiter pour les pousser vers le fork distant. Pour ajouter ce fichier à la liste de commit, tapez ce qui suit :

    + 
    git add README.md
    +
    +

    Note : README.md est le chemin d'accès au fichier que vous avez modifié, pas seulement son nom. S'il était à l'intérieur d'un sous-répertoire, vous auriez dû écrire le chemin complet du fichier.

    +
    +
    4. +
  4. +

    Si vous exécutez git status à nouveau, vous verrez maintenant ceci :

    + 
    On branch test-branch
+    Your branch is up to date with 'origin/test-branch'.
+
+    Changes to be committed:
+      (use "git restore --staged <file>..." to unstage)
+        modified:   README.md
    +
    5. +
  5. +

    Git nous dit que README.md est maintenant dans notre liste de commit. Pour inclure tous les fichiers de la liste de commit dans un commit (un seul ensemble de changements que nous essaierons plus tard d'envoyer à la branche principale), entrez ce qui suit (l'option -m est l'abréviation de « message ») :

    + 
    git commit -m 'my first commit'
    +

    Git vous dira ceci :

    + 
    [test-branch 44b207ef6] my first commit
+     1 file changed, 1 insertion(+), 1 deletion(-)
    +

    Pour montrer qu'il a enregistré que vous avez fait un commit.

    +
    6. +
  6. +

    Exécutez git status à nouveau, et vous obtiendrez cette information :

    + 
    On branch test-branch
+    Your branch is ahead of 'origin/test-branch' by 1 commit.
+      (use "git push" to publish your local commits)
+
+    nothing to commit, working tree clean
    +
    7. +
+ +

La lecture de l'information a fondamentalement été réinitialisée - elle nous dit qu'il n'y a pas de changements à soumettre, parce que nous avons maintenant envoyé notre changement précédent dans le système comme un commit. La principale différence par rapport à la version précédente est la ligne "Votre branche est en avance sur 'origin/test-branch' de 1 commit". - notre version locale de la branche "test-branch" est maintenant en avance sur la version distante de "test-branch" d'un commit - en d'autres termes, nous avons fait un changement localement que la branche distante n'a pas.

+ +

Envoyons notre changement local à la branche distante. Vous pouvez le faire en exécutant la commande git push - essayez maintenant. S'il n'y a pas d'erreurs, vous devriez obtenir un affichage comme celui-ci :

+ +
Enumerating objects: 5, done.
+Counting objects: 100% (5/5), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (3/3), done.
+Writing objects: 100% (3/3), 292 bytes | 292.00 KiB/s, done.
+Total 3 (delta 2), reused 0 (delta 0)
+remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
+To github.com:chrisdavidmills/content.git
+    77215e31e..44b207ef6  test-branch -> test-branch
+ +

Création d'une demande de triage

+ +

À ce stade, retournez sur la page github.com de votre dépôt distant. Vous devriez voir un message du type « This branch is 1 commit ahead of mdn:main. ». Ce qui signifie que le contenu de notre bifurcation contient un changement de contenu (commit) que la branche « main » de Mozilla ne contient pas.

+ +
    +
  1. +

    Pour envoyer notre modification vers la copie principale du dépôt, nous devons créer une demande de modification. Cela peut être fait facilement en utilisant le bouton "Compare & pull request" que vous devriez voir en haut de la liste des fichiers, une fois que la branche a eu une modification poussée vers elle.

    + +

    bannière avec le texte test-branch had recent pushes, et un bouton intitulé compare and pull request

    + +

    Appuyez sur ce bouton, et vous devriez obtenir un nouvel écran qui s'affiche comme suit :

    + +

    un formulaire de demande de triage ouvert, qui comprend des champs de texte pour le titre et la description

    + +
    +

    Attention : Ne suivez le reste de ces étapes que si vous avez une réelle modification à apporter au dépôt ! Veuillez ne pas soumettre de PR de test à nos dépôts.

    +
    +
    2. +
  2. +

    À ce stade, entrez un titre et une description utiles pour votre PR, en disant exactement ce qu'il a changé, pourquoi c'est une bonne chose, et quel problème connexe il a corrigé, le cas échéant. Plus précisément, incluez une ligne disant Fixes issue-url. GitHub rend automatiquement cela comme un lien vers le numéro de problème, par exemple Fixes #1234 et, en outre, ferme automatiquement le problème connexe une fois que la pull request est fusionnée.

    +
    3. +
  3. +

    Une fois que vous êtes prêt à envoyer votre pull request, cliquez sur le bouton « Create pull request ». Votre pull request (PR) apparaîtra alors dans la liste « Pull requests » du dépôt, où elle sera examinée par nos équipes de révision et, si possible, fusionnée dans le code principal.

    +

    Si l'équipe de révision souhaite que vous apportiez des modifications, elle vous en informera dans les commentaires du fil de discussion de la demande de triage (vous devriez recevoir une notification par courriel pour vous en informer).

    +
    4. +
  4. +

    Si vous souhaitez apporter d'autres modifications à la même demande de dépôt que vous avez déjà soumise, vous pouvez le faire en faisant d'autres commits sur la même branche locale et en les poussant ensuite comme expliqué précédemment. Il n'est pas nécessaire de créer une demande de pull complètement nouvelle. Veuillez simplement vous assurer que vous les faites sur la même branche que précédemment.

    +
    5. +
+ +

Dépannage

+ +

Le tutoriel ci-dessus vise à vous fournir les bases de Git et de GitHub dont vous aurez besoin pour contribuer aux dépôts GitHub à un niveau de base. Nous espérons qu'il vous a été utile ! Nous aimerions également aborder le fait que, bien qu'étant le système de contrôle de version standard de l'industrie du web, Git a une sorte de réputation mythique/légendaire d'outil péniblement difficile à apprendre et à utiliser.

+ +

Nous ne sommes pas sûrs que ce soit tout à fait juste. Git comporte de nombreuses commandes qui sont parfois assez cryptiques dans leur utilisation, et il faut beaucoup de temps pour les maîtriser. Il est également juste de dire que si vous oubliez certaines commandes ou que vous faites les choses dans le mauvais ordre, vous pouvez vous retrouver dans un désordre intéressant dont il est difficile de se sortir. Toutefois, si vous prenez les bonnes habitudes décrites ci-dessus, vous ne devriez pas trop vous tromper. Il convient également de mentionner que Git est beaucoup plus facile à utiliser qu'il y a dix ans.

+ +

Cette section sera complétée au fil du temps et comprendra des commandes/séquences utiles pour vous aider à résoudre les problèmes courants.

+ +

Annulation d'une modification que vous avez apportée à un fichier que vous n'avez pas encore ajouté à la liste des commits.

+ +

Si vous avez modifié un fichier, mais que vous n'avez pas encore exécuté la commande git add file-path pour l'ajouter à la liste des commits, vous pouvez revenir à l'état dans lequel il était lorsque vous avez extrait la branche pour la première fois en exécutant :

+ +
git restore file-path
+ +

Suppression d'un fichier de la liste de commit

+ +

Si vous avez déjà exécuté la commande git add file-path pour ajouter un fichier à la liste de commit, mais que vous voulez maintenant le supprimer de la liste de commit, vous pouvez utiliser la commande :

+ +
git restore --staged file-path
+ +

Annuler un commit

+ +

Si vous avez soumis la liste de commit en utilisant git commit -m 'mon message de commit', et que vous ne l'avez pas encore poussé, mais que vous vous êtes maintenant rendu compte que vous avez mis quelque chose dedans que vous voulez enlever, vous pouvez inverser votre commit local en utilisant :

+ +
git reset HEAD~1
+ +

Cela vous ramènera à l'état où les changements de ce commit ne sont pas encore ajoutés à la liste des commits (vous devrez les ajouter à nouveau dans git après avoir résolu le problème). Notez que cela vous ramène à l'état avant que vous ne commitiez quoi que ce soit dans cette session. Cela ne vous aidera pas si vous avez besoin de faire quelque chose de plus complexe, comme revenir sur le commit du milieu d'un ensemble de trois. Nous en resterons là pour cette leçon.

+ +

Inverser un commit qui a été poussé vers la bifurcation distante

+ +

À ce stade, il n'est pas vraiment possible de revenir en arrière, ou de rembobiner. Au lieu de cela, vous devez pousser un autre commit pour inverser les effets de celui dont vous voulez vous débarrasser. Vous pourriez le faire manuellement en utilisant certains des outils que nous vous avons déjà donnés ci-dessus, mais il y a une commande intégrée qui rend cela plus facile - git revert. Cela peut être utilisé pour créer automatiquement un commit qui rétablit les changements au point que vous spécifiez.

+ +
    +
  1. +

    Dans sa forme la plus simple, vous pouvez exécuter la commande suivante pour créer un commit qui ramènera votre branche distante à l'état dans lequel vous étiez avant de commencer à soumettre le commit :

    + 
    git revert HEAD
    +
    2. +
  2. +

    Cela aura pour conséquence l'ouverture d'un fichier de message de commit dans votre éditeur de texte par défaut que vous devrez vérifier pour vous assurer que vous êtes satisfait. Fermez-le, et git finalisera la création du commit.

    +
    3. +
  3. +

    Maintenant, il faut juste le pousser :

    + 
    git push
    +
    4. +
+ +

Si vous regardez à nouveau la page github.com de votre bifurcation distante, vous verrez le commit que vous vouliez inverser, plus le commit qui l'inverse.

+ +
+

Note : Une autre façon de se débarrasser de fichiers qui se sont retrouvés dans des demandes de triage que vous ne voulez pas voir figurer est d'utiliser l'interface utilisateur de GitHub. Allez sur la page de votre demande sur github.com, allez dans l'onglet « Files changed », et trouvez le fichier que vous voulez supprimer de la demande. En haut à droite de la boîte du fichier dans la page, il y aura un menu à « trois points » (...). Appuyez sur ce bouton et choisissez « Delete file ». Dans la page de confirmation, entrez un titre pour le nouveau commit, assurez-vous que la case « Commit directly... « est cochée, et appuyez sur le bouton « Commit changes ».

+

C'est généralement une bonne idée de faire en sorte que le reste de la demande de trisage ressemble exactement à ce que vous voulez avant de faire des changements via l'interface utilisateur de GitHub. Si vous faites quelque chose comme ça et que vous devez ensuite faire d'autres changements, vous devrez vous rappeler de tirer les changements que vous avez faits sur votre branche distante vers votre branche locale (par exemple avec git pull) avant de pouvoir pousser d'autres commits.

+
+ +

Vous voulez en voir plus ?

+ +

Si vous pensez que ce guide de dépannage devrait contenir plus d'informations, veuillez créer un ticket pour suggérer ce que vous pensez que nous devrions inclure.

+ +

Voir aussi

+ + diff --git a/files/fr/mdn/contribute/github_best_practices/index.html b/files/fr/mdn/contribute/github_best_practices/index.html deleted file mode 100644 index 146496aba9..0000000000 --- a/files/fr/mdn/contribute/github_best_practices/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Bonnes pratiques GitHub pour MDN -slug: MDN/Contribute/GitHub_best_practices -tags: - - Best practices - - Community - - GitHub - - MDN -translation_of: MDN/Contribute/GitHub_best_practices ---- -

{{MDNSidebar}}

- -

Cette page contient les bonnes pratiques pour travailler avec GitHub et contribuer à MDN, principalement axées sur la façon de travailler avec les issues qui sont les tickets/points à traiter, référencés sur les dépôts GitHub.

- -

Choisir une issue GitHub sur laquelle travailler

- -
    -
  1. Écrivez un commentaire dans le ticket en disant que vous aimeriez vous en occuper, et nous vous y affecterons. -
      -
    • Si quelqu'un d'autre est déjà affecté au problème : -
        -
      1. Si cela s'est passé il y a plus d'une semaine et qu'il n'y a pas eu beaucoup d'activité, mentionnez-les personnes et demandez-leur si vous pouvez reprendre le ticket ou les aider à terminer le projet. -
          -
        • S'ils sont d'accord pour que vous preniez l'issue, nous vous y affecterons et nous les retirerons.
          • -
        • S'ils sont d'accord pour que vous le preniez et qu'une partie du travail a déjà été effectuée, ou si l'accord prévoit que vous les aidiez, nous vous y affecterons à leurs côtés.
          • -
        -
        2. -
      2. Si c'était il y a moins d'une semaine, soyez patient et donnez-leur une chance d'y travailler.
        3. -
      -
      • -
    -
    2. -
  2. Si l'issue a été marquée comme terminée mais qu'une revue est nécessaire et que vous souhaitez relire, mentionnez la personne (@pseudo) dans les commentaires et dites que vous allez relire ses modifications.
    3. -
- -

Lorsque vous êtes affecté⋅e à une issue

- -
    -
  1. Déterminez le reste des travaux à effectuer. -
      -
    • Si l'issue est bien décrite et que le travail est assez évident, foncez et faites-le.
      • -
    • Si l'issue n'est pas bien décrite, et/ou si vous n'êtes pas sûr⋅e de ce qui est nécessaire, n'hésitez pas à @mentionner la personne à l'origine et à demander plus d'informations.
      • -
    • Si vous ne savez toujours pas à qui vous adresser, demandez de l'aide dans le salon de discussion MDN Web Docs FR sur Matrix.
      • -
    -
    2. -
  2. Une fois que vous pensez avoir résolu une issue, demandez une revue dans les commentaires.
    3. -
  3. Une fois qu'une issue a été revue avec succès et que les commentaires ont reçu une réponse positive, vous pouvez la marquer comme terminée.
    4. -
  4. Si vous n'avez plus le temps de travailler sur une issue, faites-le nous savoir dans un commentaire afin que nous puissions l'attribuer à quelqu'un d'autre.
    5. -
diff --git a/files/fr/mdn/contribute/github_best_practices/index.md b/files/fr/mdn/contribute/github_best_practices/index.md new file mode 100644 index 0000000000..146496aba9 --- /dev/null +++ b/files/fr/mdn/contribute/github_best_practices/index.md @@ -0,0 +1,49 @@ +--- +title: Bonnes pratiques GitHub pour MDN +slug: MDN/Contribute/GitHub_best_practices +tags: + - Best practices + - Community + - GitHub + - MDN +translation_of: MDN/Contribute/GitHub_best_practices +--- +

{{MDNSidebar}}

+ +

Cette page contient les bonnes pratiques pour travailler avec GitHub et contribuer à MDN, principalement axées sur la façon de travailler avec les issues qui sont les tickets/points à traiter, référencés sur les dépôts GitHub.

+ +

Choisir une issue GitHub sur laquelle travailler

+ +
    +
  1. Écrivez un commentaire dans le ticket en disant que vous aimeriez vous en occuper, et nous vous y affecterons. +
      +
    • Si quelqu'un d'autre est déjà affecté au problème : +
        +
      1. Si cela s'est passé il y a plus d'une semaine et qu'il n'y a pas eu beaucoup d'activité, mentionnez-les personnes et demandez-leur si vous pouvez reprendre le ticket ou les aider à terminer le projet. +
          +
        • S'ils sont d'accord pour que vous preniez l'issue, nous vous y affecterons et nous les retirerons.
          • +
        • S'ils sont d'accord pour que vous le preniez et qu'une partie du travail a déjà été effectuée, ou si l'accord prévoit que vous les aidiez, nous vous y affecterons à leurs côtés.
          • +
        +
        2. +
      2. Si c'était il y a moins d'une semaine, soyez patient et donnez-leur une chance d'y travailler.
        3. +
      +
      • +
    +
    2. +
  2. Si l'issue a été marquée comme terminée mais qu'une revue est nécessaire et que vous souhaitez relire, mentionnez la personne (@pseudo) dans les commentaires et dites que vous allez relire ses modifications.
    3. +
+ +

Lorsque vous êtes affecté⋅e à une issue

+ +
    +
  1. Déterminez le reste des travaux à effectuer. +
      +
    • Si l'issue est bien décrite et que le travail est assez évident, foncez et faites-le.
      • +
    • Si l'issue n'est pas bien décrite, et/ou si vous n'êtes pas sûr⋅e de ce qui est nécessaire, n'hésitez pas à @mentionner la personne à l'origine et à demander plus d'informations.
      • +
    • Si vous ne savez toujours pas à qui vous adresser, demandez de l'aide dans le salon de discussion MDN Web Docs FR sur Matrix.
      • +
    +
    2. +
  2. Une fois que vous pensez avoir résolu une issue, demandez une revue dans les commentaires.
    3. +
  3. Une fois qu'une issue a été revue avec succès et que les commentaires ont reçu une réponse positive, vous pouvez la marquer comme terminée.
    4. +
  4. Si vous n'avez plus le temps de travailler sur une issue, faites-le nous savoir dans un commentaire afin que nous puissions l'attribuer à quelqu'un d'autre.
    5. +
diff --git a/files/fr/mdn/contribute/github_cheatsheet/index.html b/files/fr/mdn/contribute/github_cheatsheet/index.html deleted file mode 100644 index 1dddbb8be7..0000000000 --- a/files/fr/mdn/contribute/github_cheatsheet/index.html +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Aide-mémoire GitHub -slug: MDN/Contribute/GitHub_cheatsheet -tags: - - Best practices - - Community - - GitHub - - MDN - - Beginners - - Cheatsheet - - Commands -translation_of: MDN/Contribute/GitHub_cheatsheet ---- -

{{MDNSidebar}}

- -

Cet article fournit une référence rapide aux commandes essentielles dont vous aurez besoin lorsque vous utiliserez Git et GitHub pour contribuer à MDN. Si vous êtes novice dans l'utilisation de ces outils et avez besoin d'un coup de pouce, notre tutoriel GitHub pour les débutants vous enseigne les bases.

- -

Cloner

- -
git clone url-du-depot
- -

Configurer une référence à un dépôt distant

- -
git remote add nom-ref-distante url-du-depot-distant-a-referencer
- -

Afficher la liste des références distantes

- -
git remote -v
- -

Préparer une modification du dépôt

- -

Basculer sur la branche principale

- -
git switch main
- -

Mettre à jour votre branche principale

- -
git fetch nom-ref-distante
-git rebase nom-ref-distante/main
-git push
- -

Obtenir sa branche en local et basculer sur celle-ci

- -
git pull
-git switch nouvelle-branche
- -

Obtenir le dernier statut

- -
git status
- -

Ajouter, valider et pousser les changements

- -
git add chemin-fichier-modifie
-git commit -m 'mon message de commit'
-git push
- -

Dépannage

- -

Annuler une modification non indexée

- -
git restore chemin-du-fichier
- -

Retirer un fichier de l'index

- -
git restore --staged chemin-du-fichier
- -

Annuler le dernier commit

- -
git reset HEAD~1
- -

Inverser un commit qui a été poussé vers la bifurcation distante

- -
git revert HEAD
-git push
- -
-

Note : Une autre façon de se débarrasser de fichiers qui se sont retrouvés dans des pull requests (demandes de triage) que vous ne voulez pas voir figurer est d'utiliser l'interface utilisateur de GitHub. Allez sur la page de votre demande sur github.com, allez dans l'onglet « Files changed », et trouvez le fichier que vous voulez supprimer de la demande. En haut à droite de la boîte du fichier dans la page, il y aura un menu à « trois points » (...). Appuyez sur ce bouton et choisissez « Delete file ». Dans la page de confirmation, entrez un titre pour le nouveau commit, assurez-vous que la case « Commit directly… » est cochée, et appuyez sur le bouton « Commit changes ».

-
- -

Vous voulez en voir plus ?

- -

Si vous pensez que cet aide-mémoire devrait contenir plus de commandes, veuillez créer un ticket pour suggérer ce que vous pensez que nous devrions inclure.

diff --git a/files/fr/mdn/contribute/github_cheatsheet/index.md b/files/fr/mdn/contribute/github_cheatsheet/index.md new file mode 100644 index 0000000000..1dddbb8be7 --- /dev/null +++ b/files/fr/mdn/contribute/github_cheatsheet/index.md @@ -0,0 +1,82 @@ +--- +title: Aide-mémoire GitHub +slug: MDN/Contribute/GitHub_cheatsheet +tags: + - Best practices + - Community + - GitHub + - MDN + - Beginners + - Cheatsheet + - Commands +translation_of: MDN/Contribute/GitHub_cheatsheet +--- +

{{MDNSidebar}}

+ +

Cet article fournit une référence rapide aux commandes essentielles dont vous aurez besoin lorsque vous utiliserez Git et GitHub pour contribuer à MDN. Si vous êtes novice dans l'utilisation de ces outils et avez besoin d'un coup de pouce, notre tutoriel GitHub pour les débutants vous enseigne les bases.

+ +

Cloner

+ +
git clone url-du-depot
+ +

Configurer une référence à un dépôt distant

+ +
git remote add nom-ref-distante url-du-depot-distant-a-referencer
+ +

Afficher la liste des références distantes

+ +
git remote -v
+ +

Préparer une modification du dépôt

+ +

Basculer sur la branche principale

+ +
git switch main
+ +

Mettre à jour votre branche principale

+ +
git fetch nom-ref-distante
+git rebase nom-ref-distante/main
+git push
+ +

Obtenir sa branche en local et basculer sur celle-ci

+ +
git pull
+git switch nouvelle-branche
+ +

Obtenir le dernier statut

+ +
git status
+ +

Ajouter, valider et pousser les changements

+ +
git add chemin-fichier-modifie
+git commit -m 'mon message de commit'
+git push
+ +

Dépannage

+ +

Annuler une modification non indexée

+ +
git restore chemin-du-fichier
+ +

Retirer un fichier de l'index

+ +
git restore --staged chemin-du-fichier
+ +

Annuler le dernier commit

+ +
git reset HEAD~1
+ +

Inverser un commit qui a été poussé vers la bifurcation distante

+ +
git revert HEAD
+git push
+ +
+

Note : Une autre façon de se débarrasser de fichiers qui se sont retrouvés dans des pull requests (demandes de triage) que vous ne voulez pas voir figurer est d'utiliser l'interface utilisateur de GitHub. Allez sur la page de votre demande sur github.com, allez dans l'onglet « Files changed », et trouvez le fichier que vous voulez supprimer de la demande. En haut à droite de la boîte du fichier dans la page, il y aura un menu à « trois points » (...). Appuyez sur ce bouton et choisissez « Delete file ». Dans la page de confirmation, entrez un titre pour le nouveau commit, assurez-vous que la case « Commit directly… » est cochée, et appuyez sur le bouton « Commit changes ».

+
+ +

Vous voulez en voir plus ?

+ +

Si vous pensez que cet aide-mémoire devrait contenir plus de commandes, veuillez créer un ticket pour suggérer ce que vous pensez que nous devrions inclure.

diff --git a/files/fr/mdn/contribute/help_beginners/index.html b/files/fr/mdn/contribute/help_beginners/index.html deleted file mode 100644 index 92c94bb627..0000000000 --- a/files/fr/mdn/contribute/help_beginners/index.html +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Aider les débutants à apprendre sur MDN ! -slug: MDN/Contribute/Help_beginners -tags: - - Beginner - - Contribute - - HELP - - Learning - - MDN -translation_of: MDN/Contribute/Help_beginners ---- -

{{MDNSidebar}}

- -

Nos pages Apprendre le développement web obtiennent plus d'un million de vues par mois, et ont des forums actifs où les utilisateurs vont pour demander une aide générale, ou demander que leurs évaluations soient notées. Nous aimerions avoir de l'aide pour répondre aux messages et développer notre communauté d'apprentissage.

- -

De quoi avons-nous besoin ?

- -

Dans le forum d'apprentissage du MDN, il existe deux principaux types de messages auxquels nous aimerions que vous nous aidiez à répondre :

- -
    -
  1. Questions générales sur le développement web.
    2. -
  2. Questions spécifiques demandant de l'aide ou une évaluation des tests de compétences et des évaluations qui figurent dans la section Apprendre le développement web de MDN.
    3. -
- -

Comment pouvez-vous en profiter ?

- - - -

Quelles sont les compétences dont vous avez besoin ?

- - - -

Comment aider

- -
    -
  1. Tout d'abord, créez-vous un compte MDN, si vous n'en avez pas déjà un. Vous n'avez pas nécessairement besoin de le faire pour contribuer à l'espace d'apprentissage, mais cela vous sera utile à long terme.
    2. -
  2. Inscrivez-vous également à Mozilla Discourse, si ce n'est pas déjà fait.
    3. -
  3. Jetez un coup d'œil à la section Apprendre le développement web et acquérez un niveau de familiarité de base avec ce qui s'y trouve, si ce n'est pas déjà fait (voir la section Structure de l'espace d'apprentissage MDN ci-dessous pour vous aider).
    4. -
- -

Une fois que vous êtes prêt

- -
    -
  1. Jetez un coup d'œil au forum d'apprentissage et voyez s'il y a des messages qui n'ont pas de réponses - c'est le meilleur endroit pour commencer. -
      -
    • Conseil : si vous ne trouvez aucune réponse, consultez les autres pages qui ont été récemment mises à jour et voyez si vous pouvez ajouter quelque chose d'utile qui n'a pas déjà été dit.
      • -
    -
    2. -
  2. Si le message auquel vous répondez est une demande d'aide générale, répondez-lui et donnez-lui autant d'aide que vous en avez le temps.
    3. -
  3. Si le message auquel vous répondez demande une évaluation pour l'une des tâches "tester vos compétences"/"évaluation" : -
      -
    1. Identifiez l'article/tâche évalué(e) et trouvez le guide de notation qui lui est associé. Vous pouvez tout à fait demander à la personne qui a envoyé le message si elle peut vous donner le lien vers l'évaluation/le test de compétences.
      2. -
    2. Identifiez le code de la personne - elle devrait vous le donner sous la forme d'un lien CodePen/JSFiddle/JSBin, ou similaire. Si elle ne le fournit pas sous une forme facile à évaluer, il est parfaitement acceptable de lui demander de le mettre dans CodePen, JSFiddle, ou similaire. -
        -
      • Un problème courant est celui des personnes qui publient leur code directement dans un message de discourse - discourse rend les éléments HTML et transforme les guillemets en smartquotes, ce qui casse le code. Il est préférable de l'envoyer sous forme d'URL vers une application d'édition de code partageable.
        • -
      -
      3. -
    3. Lisez le code et évaluez-le -
        -
      1. Est-ce qu'il fonctionne, et vous donne-t-il le résultat qu'il devrait donner ?
        2. -
      2. Si non, pourquoi ne fonctionne-t-il pas ?
        3. -
      3. Avez-vous des conseils à donner à la personne pour améliorer le code (plus efficace, meilleure pratique, etc.) ?
        4. -
      -
      4. -
    4. Donnez-leur un rapport sur leurs résultats : -
        -
      1. Certains guides de notation suggèrent un schéma de notation avec des points pour chaque partie de la question, mais vous n'avez pas besoin d'être aussi précis.
        2. -
      2. Si la personne s'est bien débrouillée, à l'exception de quelques détails, dites-lui ces détails, mais félicitez-la aussi.
        3. -
      3. Si la personne était sur le point d'atteindre son objectif, mais que son travail n'était pas tout à fait correct, dites-lui qu'elle s'est très bien débrouillée, mais indiquez-lui les corrections à apporter pour que cela fonctionne, et peut-être même un lien vers le guide de notation pour qu'elle puisse voir ce que nous avons fait.
        4. -
      4. Si la personne est loin d'avoir trouvé une solution, soyez gentil et encourageant et essayez de lui donner quelques indices sur la direction à prendre. Donnez-lui une autre chance d'essayer de faire mieux.
        5. -
      5. Si vous avez besoin d'aide pour quoi que ce soit, demandez de l'aide dans le salon de discussion MDN Web Docs sur Matrix.
        6. -
      -
      5. -
    -
    4. -
- -
-

Attention : Avant tout, soyez patient, amical et aimable. N'oubliez pas que la plupart de ces personnes sont des débutants.

-
- -

Structure de l'espace d'apprentissage MDN

- -

Lorsque vous aidez à répondre aux questions liées à la section Apprendre le développement web de MDN, il est bon d'y jeter un coup d'œil et d'acquérir un niveau de familiarité de base avec ce qui s'y trouve.

- -
    -
  1. Examinez la structure de la page en général.
    2. -
  2. Regardez en particulier les types d'évaluations disponibles, - -
    3. -
  3. Jetez un œil aux dépôts GitHub associés à la zone d'apprentissage (la plupart des fichiers sont disponibles dans https://github.com/mdn/learning-area/, certains sont dans https://github.com/mdn/css-examples/tree/master/learn). La plupart des exemples sur lesquels les apprenants voudront de l'aide sont contenus ici.
    4. -
  4. Chaque évaluation/épreuve de compétence est associée à un guide de notation et à une solution recommandée pour vous aider à évaluer leur travail.
    5. -
  5. Il existe des modèles qui facilitent la recherche de ces ressources, par exemple : - -
    6. -
- -

Il vous semblera difficile de naviguer dans tout cela au début, mais vous trouverez cela plus facile avec le temps, à mesure que vous vous familiariserez avec les exercices.

diff --git a/files/fr/mdn/contribute/help_beginners/index.md b/files/fr/mdn/contribute/help_beginners/index.md new file mode 100644 index 0000000000..92c94bb627 --- /dev/null +++ b/files/fr/mdn/contribute/help_beginners/index.md @@ -0,0 +1,111 @@ +--- +title: Aider les débutants à apprendre sur MDN ! +slug: MDN/Contribute/Help_beginners +tags: + - Beginner + - Contribute + - HELP + - Learning + - MDN +translation_of: MDN/Contribute/Help_beginners +--- +

{{MDNSidebar}}

+ +

Nos pages Apprendre le développement web obtiennent plus d'un million de vues par mois, et ont des forums actifs où les utilisateurs vont pour demander une aide générale, ou demander que leurs évaluations soient notées. Nous aimerions avoir de l'aide pour répondre aux messages et développer notre communauté d'apprentissage.

+ +

De quoi avons-nous besoin ?

+ +

Dans le forum d'apprentissage du MDN, il existe deux principaux types de messages auxquels nous aimerions que vous nous aidiez à répondre :

+ +
    +
  1. Questions générales sur le développement web.
    2. +
  2. Questions spécifiques demandant de l'aide ou une évaluation des tests de compétences et des évaluations qui figurent dans la section Apprendre le développement web de MDN.
    3. +
+ +

Comment pouvez-vous en profiter ?

+ + + +

Quelles sont les compétences dont vous avez besoin ?

+ + + +

Comment aider

+ +
    +
  1. Tout d'abord, créez-vous un compte MDN, si vous n'en avez pas déjà un. Vous n'avez pas nécessairement besoin de le faire pour contribuer à l'espace d'apprentissage, mais cela vous sera utile à long terme.
    2. +
  2. Inscrivez-vous également à Mozilla Discourse, si ce n'est pas déjà fait.
    3. +
  3. Jetez un coup d'œil à la section Apprendre le développement web et acquérez un niveau de familiarité de base avec ce qui s'y trouve, si ce n'est pas déjà fait (voir la section Structure de l'espace d'apprentissage MDN ci-dessous pour vous aider).
    4. +
+ +

Une fois que vous êtes prêt

+ +
    +
  1. Jetez un coup d'œil au forum d'apprentissage et voyez s'il y a des messages qui n'ont pas de réponses - c'est le meilleur endroit pour commencer. +
      +
    • Conseil : si vous ne trouvez aucune réponse, consultez les autres pages qui ont été récemment mises à jour et voyez si vous pouvez ajouter quelque chose d'utile qui n'a pas déjà été dit.
      • +
    +
    2. +
  2. Si le message auquel vous répondez est une demande d'aide générale, répondez-lui et donnez-lui autant d'aide que vous en avez le temps.
    3. +
  3. Si le message auquel vous répondez demande une évaluation pour l'une des tâches "tester vos compétences"/"évaluation" : +
      +
    1. Identifiez l'article/tâche évalué(e) et trouvez le guide de notation qui lui est associé. Vous pouvez tout à fait demander à la personne qui a envoyé le message si elle peut vous donner le lien vers l'évaluation/le test de compétences.
      2. +
    2. Identifiez le code de la personne - elle devrait vous le donner sous la forme d'un lien CodePen/JSFiddle/JSBin, ou similaire. Si elle ne le fournit pas sous une forme facile à évaluer, il est parfaitement acceptable de lui demander de le mettre dans CodePen, JSFiddle, ou similaire. +
        +
      • Un problème courant est celui des personnes qui publient leur code directement dans un message de discourse - discourse rend les éléments HTML et transforme les guillemets en smartquotes, ce qui casse le code. Il est préférable de l'envoyer sous forme d'URL vers une application d'édition de code partageable.
        • +
      +
      3. +
    3. Lisez le code et évaluez-le +
        +
      1. Est-ce qu'il fonctionne, et vous donne-t-il le résultat qu'il devrait donner ?
        2. +
      2. Si non, pourquoi ne fonctionne-t-il pas ?
        3. +
      3. Avez-vous des conseils à donner à la personne pour améliorer le code (plus efficace, meilleure pratique, etc.) ?
        4. +
      +
      4. +
    4. Donnez-leur un rapport sur leurs résultats : +
        +
      1. Certains guides de notation suggèrent un schéma de notation avec des points pour chaque partie de la question, mais vous n'avez pas besoin d'être aussi précis.
        2. +
      2. Si la personne s'est bien débrouillée, à l'exception de quelques détails, dites-lui ces détails, mais félicitez-la aussi.
        3. +
      3. Si la personne était sur le point d'atteindre son objectif, mais que son travail n'était pas tout à fait correct, dites-lui qu'elle s'est très bien débrouillée, mais indiquez-lui les corrections à apporter pour que cela fonctionne, et peut-être même un lien vers le guide de notation pour qu'elle puisse voir ce que nous avons fait.
        4. +
      4. Si la personne est loin d'avoir trouvé une solution, soyez gentil et encourageant et essayez de lui donner quelques indices sur la direction à prendre. Donnez-lui une autre chance d'essayer de faire mieux.
        5. +
      5. Si vous avez besoin d'aide pour quoi que ce soit, demandez de l'aide dans le salon de discussion MDN Web Docs sur Matrix.
        6. +
      +
      5. +
    +
    4. +
+ +
+

Attention : Avant tout, soyez patient, amical et aimable. N'oubliez pas que la plupart de ces personnes sont des débutants.

+
+ +

Structure de l'espace d'apprentissage MDN

+ +

Lorsque vous aidez à répondre aux questions liées à la section Apprendre le développement web de MDN, il est bon d'y jeter un coup d'œil et d'acquérir un niveau de familiarité de base avec ce qui s'y trouve.

+ +
    +
  1. Examinez la structure de la page en général.
    2. +
  2. Regardez en particulier les types d'évaluations disponibles, + +
    3. +
  3. Jetez un œil aux dépôts GitHub associés à la zone d'apprentissage (la plupart des fichiers sont disponibles dans https://github.com/mdn/learning-area/, certains sont dans https://github.com/mdn/css-examples/tree/master/learn). La plupart des exemples sur lesquels les apprenants voudront de l'aide sont contenus ici.
    4. +
  4. Chaque évaluation/épreuve de compétence est associée à un guide de notation et à une solution recommandée pour vous aider à évaluer leur travail.
    5. +
  5. Il existe des modèles qui facilitent la recherche de ces ressources, par exemple : + +
    6. +
+ +

Il vous semblera difficile de naviguer dans tout cela au début, mais vous trouverez cela plus facile avec le temps, à mesure que vous vous familiariserez avec les exercices.

diff --git a/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.html b/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.html deleted file mode 100644 index 5575715390..0000000000 --- a/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.html +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Comment convertir des exemples de code pour qu'ils soient "live" -slug: MDN/Contribute/Howto/Convert_code_samples_to_be_live -translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live -original_slug: MDN/Contribute/Howto/convertir_code_pour_etre_direct ---- -
{{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".

- -

Compétences nécessaires pour cette tâche

- - - -

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/convert_code_samples_to_be_live/index.md b/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.md new file mode 100644 index 0000000000..5575715390 --- /dev/null +++ b/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.md @@ -0,0 +1,27 @@ +--- +title: Comment convertir des exemples de code pour qu'ils soient "live" +slug: MDN/Contribute/Howto/Convert_code_samples_to_be_live +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +original_slug: MDN/Contribute/Howto/convertir_code_pour_etre_direct +--- +
{{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".

+ +

Compétences nécessaires pour cette tâche

+ + + +

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/create_and_edit_pages/index.html b/files/fr/mdn/contribute/howto/create_and_edit_pages/index.html deleted file mode 100644 index 70cb353739..0000000000 --- a/files/fr/mdn/contribute/howto/create_and_edit_pages/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Créer et modifier des pages -slug: MDN/Contribute/Howto/Create_and_edit_pages -translation_of: 'MDN/Contribute/Howto/Create_and_edit_pages' ---- -
{{MDNSidebar}}
- -

Cet article est destiné à présenter aux personnes souhaitant contribuer à MDN le processus de modification de pages existantes et de création de nouvelles pages.

- -
-

Note : Le contenu de MDN s'organise au sein de deux dépôts Git : mdn/content avec le contenu en anglais et mdn/translated-content avec le contenu traduit (y compris en français). C'est le dépôt mdn/content qui constitue la référence. Si vous souhaitez créer une page en français, celle-ci devra au préalable avoir été créée en anglais.

-
-

Modifier une page existante

- -

Pour modifier une page, vous devez trouver la page source :

-. -

La façon la plus rapide de la trouver est d'aller sur la page que vous souhaitez modifier, puis de vous rendre en bas de cette page et enfin de cliquer sur le lien « Source on GitHub ».

- -

Une fois que vous avez trouvé la source à modifier, rendez-vous sur notre fichier README et parcourez notre guide sur la contribution (en anglais). Vous pouvez également consulter ce billet en français pour savoir comment contribuer.

- -

Prévisualiser vos modifications

- -

SI vous modifiez la page en local, vous pouvez voir à quoi ressembleront vos modifications en allant sur le dossier du dépôt nommé content, en exécutant la commande CLI yarn start, puis en vous rendant à l'URL localhost:5000 dans votre navigateur, et enfin en retrouvant la page sur laquelle vous travaillez. Pour la trouver plus facilement, utilisez la boîte de recherche. La page que vous prévisualisez sera rafraîchie automatiquement au fur et à mesure que vous modifiez son code source.

- -

Ajouter des pièces jointes

- -

Pour ajouter un fichier en pièce jointe à votre article, vous avez simplement besoin de l'inclure dans le même répertoire du fichier index.html de votre article, puis de l'ajouter dans votre page, typiquement à l'aide d'un élément <a>.

- -

Créer une nouvelle page

- -

Pour créer une nouvelle page, consultez les instructions fournies sur la documentation concernant l'ajout de nouveaux documents (en anglais).

- -
-

Attention : Pour créer une page en français (ou dans une autre langue), celle-ci devra préalablement exister/avoir été créée en anglais.

-
-

Voir aussi

- - diff --git a/files/fr/mdn/contribute/howto/create_and_edit_pages/index.md b/files/fr/mdn/contribute/howto/create_and_edit_pages/index.md new file mode 100644 index 0000000000..70cb353739 --- /dev/null +++ b/files/fr/mdn/contribute/howto/create_and_edit_pages/index.md @@ -0,0 +1,44 @@ +--- +title: Créer et modifier des pages +slug: MDN/Contribute/Howto/Create_and_edit_pages +translation_of: 'MDN/Contribute/Howto/Create_and_edit_pages' +--- +
{{MDNSidebar}}
+ +

Cet article est destiné à présenter aux personnes souhaitant contribuer à MDN le processus de modification de pages existantes et de création de nouvelles pages.

+ +
+

Note : Le contenu de MDN s'organise au sein de deux dépôts Git : mdn/content avec le contenu en anglais et mdn/translated-content avec le contenu traduit (y compris en français). C'est le dépôt mdn/content qui constitue la référence. Si vous souhaitez créer une page en français, celle-ci devra au préalable avoir été créée en anglais.

+
+

Modifier une page existante

+ +

Pour modifier une page, vous devez trouver la page source :

+. +

La façon la plus rapide de la trouver est d'aller sur la page que vous souhaitez modifier, puis de vous rendre en bas de cette page et enfin de cliquer sur le lien « Source on GitHub ».

+ +

Une fois que vous avez trouvé la source à modifier, rendez-vous sur notre fichier README et parcourez notre guide sur la contribution (en anglais). Vous pouvez également consulter ce billet en français pour savoir comment contribuer.

+ +

Prévisualiser vos modifications

+ +

SI vous modifiez la page en local, vous pouvez voir à quoi ressembleront vos modifications en allant sur le dossier du dépôt nommé content, en exécutant la commande CLI yarn start, puis en vous rendant à l'URL localhost:5000 dans votre navigateur, et enfin en retrouvant la page sur laquelle vous travaillez. Pour la trouver plus facilement, utilisez la boîte de recherche. La page que vous prévisualisez sera rafraîchie automatiquement au fur et à mesure que vous modifiez son code source.

+ +

Ajouter des pièces jointes

+ +

Pour ajouter un fichier en pièce jointe à votre article, vous avez simplement besoin de l'inclure dans le même répertoire du fichier index.html de votre article, puis de l'ajouter dans votre page, typiquement à l'aide d'un élément <a>.

+ +

Créer une nouvelle page

+ +

Pour créer une nouvelle page, consultez les instructions fournies sur la documentation concernant l'ajout de nouveaux documents (en anglais).

+ +
+

Attention : Pour créer une page en français (ou dans une autre langue), celle-ci devra préalablement exister/avoir été créée en anglais.

+
+

Voir aussi

+ + diff --git a/files/fr/mdn/contribute/howto/index.html b/files/fr/mdn/contribute/howto/index.html deleted file mode 100644 index 59b33bbba6..0000000000 --- a/files/fr/mdn/contribute/howto/index.html +++ /dev/null @@ -1,13 +0,0 @@ ---- -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/index.md b/files/fr/mdn/contribute/howto/index.md new file mode 100644 index 0000000000..59b33bbba6 --- /dev/null +++ b/files/fr/mdn/contribute/howto/index.md @@ -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/write_a_new_entry_in_the_glossary/index.html b/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html deleted file mode 100644 index b70818e6d9..0000000000 --- a/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html +++ /dev/null @@ -1,112 +0,0 @@ ---- -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.

- -

É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_a_new_entry_in_the_glossary/index.md b/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.md new file mode 100644 index 0000000000..b70818e6d9 --- /dev/null +++ b/files/fr/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.md @@ -0,0 +1,112 @@ +--- +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.

+ +

É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/index.html b/files/fr/mdn/contribute/index.html deleted file mode 100644 index f72eae7a86..0000000000 --- a/files/fr/mdn/contribute/index.html +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Contribuer à MDN -slug: MDN/Contribute -tags: - - Guide - - Landing - - MDN Meta -translation_of: MDN/Contribute ---- -
{{MDNSidebar}}
- -

MDN Web Docs a besoin de votre aide ! Nous avons un grand nombre de fautes de frappe à corriger, d'exemples à rédiger, de bogues à résoudre, de personnes à qui parler, et bien d'autres choses encore, et ce nombre ne cesse d'augmenter à mesure que les gens commencent à utiliser le site. Cette page présente ce que vous pouvez faire pour nous aider.

- -
-

Note : Si vous n'avez jamais contribué à MDN auparavant, le guide Pour commencer explique le processus en quatre étapes simples. Bonne nouvelle, vous en êtes déjà à l'étape 3 : « Découvrir comment vous pouvez aider » !

-
- -

Que puis-je faire pour aider ?

- -

Il existe plusieurs façons de contribuer à MDN, en fonction de vos compétences et de vos intérêts. Chaque tâche est accompagnée d'une brève description et d'une durée approximative.

- -

Si vous n'êtes pas sûr de ce que vous devez faire, vous êtes toujours invité à demander de l'aide.

- -

Principaux types de contributions

- -

Les liens de cette section mènent à des guides détaillés expliquant comment effectuer une tâche de contribution particulière pour laquelle nous sommes très intéressés par l'aide de la communauté, soit parce qu'il s'agit d'une fonction critique, soit parce qu'elle est associée à un important arriéré. Veuillez envisager d'aider à réaliser ces tâches avant d'envisager de contribuer d'une autre manière.

- - - - - - - - - - - - - - - - - - - - - - - - - - -
TâchesDescriptionCompétences requises
Correction des bogues de contenu MDNNotre dépôt mdn/translated-content est l'endroit où les gens soumettent des problèmes pour signaler les problèmes rencontrés avec les docs MDN (vous trouverez également des bogues à corriger sur l'ancien dépôt sprints, mais nous allons le fermer à terme). Nous recevons beaucoup de bugs de contenu, et toute aide que vous pouvez apporter pour les corriger serait très appréciée. -
    -
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • -
  • Une compréhension raisonnable de la langue anglaise (ne vous inquiétez pas si votre anglais n'est pas parfait, nous pouvons vous aider).
    • -
-
Révision des éditions du MDNLes gens soumettent des demandes de compilation sur notre dépôt de contenu tout le temps pour mettre à jour le contenu du MDN, et nous avons besoin d'aide pour les réviser. Rendez-vous sur notre page REVIEWING.md pour découvrir comment fonctionne le processus de révision et comment vous pouvez y participer. -
    -
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • -
  • Une compréhension raisonnable de la langue anglaise (ne vous inquiétez pas si votre anglais n'est pas parfait, nous pouvons vous aider).
    • -
-
Aider les débutants à apprendre sur MDNNos pages Apprendre le développement web obtiennent plus d'un million de vues par mois et disposent de forums actifs où les gens se rendent pour demander une aide générale ou demander que leurs évaluations soient notées. Nous aimerions avoir de l'aide pour répondre aux messages et développer notre communauté d'apprentissage. -
    -
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • -
  • Enthousiasme pour expliquer les sujets techniques et aider les débutants à apprendre à coder.
    • -
  • Maîtrise raisonnable de la langue anglaise ; il n'est pas nécessaire qu'elle soit parfaite.
    • -
-
- -

Nous ajouterons d'autres tâches ici au fil du temps.

- -

Notation des priorités

- -

Vous pouvez également consulter les classements de priorité pour vous donner une idée du travail le plus important à réaliser - nous avons commencé à donner aux problèmes de bogues de contenu les étiquettes P0, P1, P2, P3 et P4 pour indiquer leur importance, les chiffres les plus bas étant plus importants que les chiffres les plus élevés.

- -

Ils sont déterminés lors du processus régulier de triage des bogues de MDN, sur la base de la liste des priorités de la documentation MDN.

- -

Autres types de tâches

- -

Si nos principales priorités énumérées ci-dessus ne vous intéressent pas, vous trouverez ci-dessous un certain nombre d'autres types de tâches plus générales dans lesquelles vous pourrez vous impliquer, réparties par type de compétences.

- -

Si vous êtes plus intéressé par les mots, vous pouvez faire ce qui suit :

- - - -

Si vous êtes plus intéressé par le code, vous pouvez vous essayer à ce qui suit :

- - - -

Si vous vous intéressez aux mots et au code, vous pourriez vous essayer à ce qui suit :

- - - -
-

Note : Si vous avez trouvé quelque chose d'incorrect sur MDN mais que vous ne savez pas comment le corriger, vous pouvez signaler les problèmes en déposant un problème de documentation. Veuillez donner un titre descriptif au problème. (Il n'est pas utile de dire "Lien mort" sans préciser où vous avez trouvé le lien.

-
- -

Autres pages utiles

- -

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/contribute/index.md b/files/fr/mdn/contribute/index.md new file mode 100644 index 0000000000..f72eae7a86 --- /dev/null +++ b/files/fr/mdn/contribute/index.md @@ -0,0 +1,112 @@ +--- +title: Contribuer à MDN +slug: MDN/Contribute +tags: + - Guide + - Landing + - MDN Meta +translation_of: MDN/Contribute +--- +
{{MDNSidebar}}
+ +

MDN Web Docs a besoin de votre aide ! Nous avons un grand nombre de fautes de frappe à corriger, d'exemples à rédiger, de bogues à résoudre, de personnes à qui parler, et bien d'autres choses encore, et ce nombre ne cesse d'augmenter à mesure que les gens commencent à utiliser le site. Cette page présente ce que vous pouvez faire pour nous aider.

+ +
+

Note : Si vous n'avez jamais contribué à MDN auparavant, le guide Pour commencer explique le processus en quatre étapes simples. Bonne nouvelle, vous en êtes déjà à l'étape 3 : « Découvrir comment vous pouvez aider » !

+
+ +

Que puis-je faire pour aider ?

+ +

Il existe plusieurs façons de contribuer à MDN, en fonction de vos compétences et de vos intérêts. Chaque tâche est accompagnée d'une brève description et d'une durée approximative.

+ +

Si vous n'êtes pas sûr de ce que vous devez faire, vous êtes toujours invité à demander de l'aide.

+ +

Principaux types de contributions

+ +

Les liens de cette section mènent à des guides détaillés expliquant comment effectuer une tâche de contribution particulière pour laquelle nous sommes très intéressés par l'aide de la communauté, soit parce qu'il s'agit d'une fonction critique, soit parce qu'elle est associée à un important arriéré. Veuillez envisager d'aider à réaliser ces tâches avant d'envisager de contribuer d'une autre manière.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
TâchesDescriptionCompétences requises
Correction des bogues de contenu MDNNotre dépôt mdn/translated-content est l'endroit où les gens soumettent des problèmes pour signaler les problèmes rencontrés avec les docs MDN (vous trouverez également des bogues à corriger sur l'ancien dépôt sprints, mais nous allons le fermer à terme). Nous recevons beaucoup de bugs de contenu, et toute aide que vous pouvez apporter pour les corriger serait très appréciée. +
    +
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • +
  • Une compréhension raisonnable de la langue anglaise (ne vous inquiétez pas si votre anglais n'est pas parfait, nous pouvons vous aider).
    • +
+
Révision des éditions du MDNLes gens soumettent des demandes de compilation sur notre dépôt de contenu tout le temps pour mettre à jour le contenu du MDN, et nous avons besoin d'aide pour les réviser. Rendez-vous sur notre page REVIEWING.md pour découvrir comment fonctionne le processus de révision et comment vous pouvez y participer. +
    +
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • +
  • Une compréhension raisonnable de la langue anglaise (ne vous inquiétez pas si votre anglais n'est pas parfait, nous pouvons vous aider).
    • +
+
Aider les débutants à apprendre sur MDNNos pages Apprendre le développement web obtiennent plus d'un million de vues par mois et disposent de forums actifs où les gens se rendent pour demander une aide générale ou demander que leurs évaluations soient notées. Nous aimerions avoir de l'aide pour répondre aux messages et développer notre communauté d'apprentissage. +
    +
  • Connaissance des technologies web que vous choisissez d'utiliser (par exemple, JavaScript, CSS).
    • +
  • Enthousiasme pour expliquer les sujets techniques et aider les débutants à apprendre à coder.
    • +
  • Maîtrise raisonnable de la langue anglaise ; il n'est pas nécessaire qu'elle soit parfaite.
    • +
+
+ +

Nous ajouterons d'autres tâches ici au fil du temps.

+ +

Notation des priorités

+ +

Vous pouvez également consulter les classements de priorité pour vous donner une idée du travail le plus important à réaliser - nous avons commencé à donner aux problèmes de bogues de contenu les étiquettes P0, P1, P2, P3 et P4 pour indiquer leur importance, les chiffres les plus bas étant plus importants que les chiffres les plus élevés.

+ +

Ils sont déterminés lors du processus régulier de triage des bogues de MDN, sur la base de la liste des priorités de la documentation MDN.

+ +

Autres types de tâches

+ +

Si nos principales priorités énumérées ci-dessus ne vous intéressent pas, vous trouverez ci-dessous un certain nombre d'autres types de tâches plus générales dans lesquelles vous pourrez vous impliquer, réparties par type de compétences.

+ +

Si vous êtes plus intéressé par les mots, vous pouvez faire ce qui suit :

+ + + +

Si vous êtes plus intéressé par le code, vous pouvez vous essayer à ce qui suit :

+ + + +

Si vous vous intéressez aux mots et au code, vous pourriez vous essayer à ce qui suit :

+ + + +
+

Note : Si vous avez trouvé quelque chose d'incorrect sur MDN mais que vous ne savez pas comment le corriger, vous pouvez signaler les problèmes en déposant un problème de documentation. Veuillez donner un titre descriptif au problème. (Il n'est pas utile de dire "Lien mort" sans préciser où vous avez trouvé le lien.

+
+ +

Autres pages utiles

+ +

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/contribute/localize/index.html b/files/fr/mdn/contribute/localize/index.html deleted file mode 100644 index bd39293888..0000000000 --- a/files/fr/mdn/contribute/localize/index.html +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Localiser MDN -slug: MDN/Contribute/Localize -tags: - - Localization - - MDN Meta - - l10n ---- -
{{MDNSidebar}}
- -

Depuis le 14 décembre 2020, MDN fonctionne sur la nouvelle plateforme Yari basée sur GitHub. Cela présente de nombreux avantages pour MDN, mais nous avons dû apporter des changements radicaux à la façon dont nous gérons la localisation. En effet, nous nous sommes retrouvés avec un grand nombre de contenus non maintenus et obsolètes dans nos langues autres que l'anglais et nous voulons mieux les gérer à l'avenir.

- -

L'objectif est de geler tout le contenu localisé (ce qui signifie que nous n'accepterons aucune modification, il sera en lecture seule), puis de ne dégeler que les localisations pour lesquelles des équipes dédiées se chargent de leur maintenance.

- -

Langues actives

- -

Nous avons actuellement dégelé les langues suivantes :

- -
-

Note : Si vous voulez contribuer à l'une des langues actives existantes, ou si vous voulez discuter du dégel d'une langue actuellement gelée, contactez l'un des membres actifs listés ci-dessous, ou contactez-nous pour obtenir de l'aide.

-
- -

Chinois (zh-CN, zh-TW)

- - - -

Français (fr)

- - - -

Japonais (ja)

- - - -

Coréen (ko)

- - - -

Russe (ru)

- - - -

Autres sujets de localisation sur MDN

- -

Pour l'instant, la nouvelle interface utilisateur de la plateforme MDN sera uniquement en anglais. C'est un problème que nous aborderons plus tard.

- -

Les macros KumaScript continuent de fonctionner sur la nouvelle plateforme MDN, mais nous finirons par les supprimer progressivement au fur et à mesure de la construction de la nouvelle plateforme. Pour l'instant, elles continueront à fonctionner comme avant, et sont toujours éditées via des demandes de triage vers le dépôt GitHub de Yari.

- -

Voir aussi

- - diff --git a/files/fr/mdn/contribute/localize/index.md b/files/fr/mdn/contribute/localize/index.md new file mode 100644 index 0000000000..bd39293888 --- /dev/null +++ b/files/fr/mdn/contribute/localize/index.md @@ -0,0 +1,71 @@ +--- +title: Localiser MDN +slug: MDN/Contribute/Localize +tags: + - Localization + - MDN Meta + - l10n +--- +
{{MDNSidebar}}
+ +

Depuis le 14 décembre 2020, MDN fonctionne sur la nouvelle plateforme Yari basée sur GitHub. Cela présente de nombreux avantages pour MDN, mais nous avons dû apporter des changements radicaux à la façon dont nous gérons la localisation. En effet, nous nous sommes retrouvés avec un grand nombre de contenus non maintenus et obsolètes dans nos langues autres que l'anglais et nous voulons mieux les gérer à l'avenir.

+ +

L'objectif est de geler tout le contenu localisé (ce qui signifie que nous n'accepterons aucune modification, il sera en lecture seule), puis de ne dégeler que les localisations pour lesquelles des équipes dédiées se chargent de leur maintenance.

+ +

Langues actives

+ +

Nous avons actuellement dégelé les langues suivantes :

+ +
+

Note : Si vous voulez contribuer à l'une des langues actives existantes, ou si vous voulez discuter du dégel d'une langue actuellement gelée, contactez l'un des membres actifs listés ci-dessous, ou contactez-nous pour obtenir de l'aide.

+
+ +

Chinois (zh-CN, zh-TW)

+ + + +

Français (fr)

+ + + +

Japonais (ja)

+ + + +

Coréen (ko)

+ + + +

Russe (ru)

+ + + +

Autres sujets de localisation sur MDN

+ +

Pour l'instant, la nouvelle interface utilisateur de la plateforme MDN sera uniquement en anglais. C'est un problème que nous aborderons plus tard.

+ +

Les macros KumaScript continuent de fonctionner sur la nouvelle plateforme MDN, mais nous finirons par les supprimer progressivement au fur et à mesure de la construction de la nouvelle plateforme. Pour l'instant, elles continueront à fonctionner comme avant, et sont toujours éditées via des demandes de triage vers le dépôt GitHub de Yari.

+ +

Voir aussi

+ + diff --git a/files/fr/mdn/contribute/open_source_etiquette/index.html b/files/fr/mdn/contribute/open_source_etiquette/index.html deleted file mode 100644 index 2721c7985c..0000000000 --- a/files/fr/mdn/contribute/open_source_etiquette/index.html +++ /dev/null @@ -1,165 +0,0 @@ ---- -title: Étiquette de base pour les projets open source -slug: MDN/Contribute/Open_source_etiquette -tags: - - Best practices - - Community - - Open source - - MDN - - Beginners -translation_of: MDN/Contribute/Open_source_etiquette ---- -

{{MDNSidebar}}

- -

Si vous n'avez jamais travaillé sur un projet open source (OSP pour « Open Source Project ») auparavant, il est bon de lire cet article avant de commencer à contribuer à MDN (ou à d'autres projets open source). Il y a quelques bonnes pratiques à adopter qui vous permettront, à vous et aux autres contributrices et contributeurs du projet, de vous sentir valorisés et en sécurité, et de rester productifs.

- -

Cet article ne vous apprendra pas tout ce qu'il faut savoir sur la contribution à un projet open source ; l'objectif est plutôt de vous donner quelques bons points de départ sur lesquels vous pourrez réfléchir et en apprendre davantage lorsque vous commencerez à contribuer à un projet open source.

- -

Réfléchissez à la raison pour laquelle vous contribuez à un OSP

- -

Avant de commencer à contribuer à un projet open source, demandez-vous pourquoi vous voulez le faire. Si la réponse à cette question est simplement « Je m'ennuie et je veux trouver quelque chose de productif à faire avec mon temps », c'est bien, mais vous pouvez probablement aller plus loin.

- -

De meilleures raisons encore peuvent être envisagées :

- -

- -

Si vous passez votre temps à travailler gratuitement sur un projet, il est raisonnable de s'attendre à en retirer quelque chose. En fait, vous êtes beaucoup plus susceptible de rester plus longtemps et de contribuer de manière plus productive au projet. En outre, si vous avez un bon ensemble de raisons de contribuer avant de commencer, il sera plus facile de décider des tâches à entreprendre.

- -

Voici quelques raisons pour lesquelles vous ne devriez pas commencer à contribuer :

- - - -

Votre présence sur le projet doit rester productive, et ne pas empêcher les autres d'être productifs.

- -

Soyez polis, soyez aimables, évitez les propos incendiaires ou offensants.

- -

On pourrait abréger cela en disant « soyez gentil ». C'est le conseil numéro un que nous donnons à toute personne qui se lance dans les contributions open source.

- -

Soyez gentil avec les autres contributeurs du projet, et le projet sera plus agréable et plus productif. Cela inclut :

- - - -

Vous et les autres contributeurs êtes (ou devriez être) ici parce qu'ils veulent apporter une contribution positive au projet, mais au-delà de cela, vous ne pouvez rien présumer d'eux. Cela inclut leurs :

- - - -

Vous devez donc vous en tenir autant que possible au sujet, en évitant les hors-sujets potentiellement controversés comme la religion ou la politique, et en faisant preuve de soutien et de respect même si vous n'êtes pas d'accord avec quelqu'un ou si vous n'aimez pas une décision qu'il a prise.

- -

De même, vous devez vous abstenir de tout juron ou langage offensant sur MDN, même s'il n'est pas dirigé contre quelqu'un en particulier. Ce n'est pas nécessaire pour participer, et certaines personnes y sont vraiment sensibles.

- -

Sachez qu'il existe des règles dans toute bonne OSP pour protéger ses contributeurs afin qu'ils ne se sentent pas mal à l'aise lorsqu'ils contribuent. Ces règles prennent généralement la forme d'un fichier CODE_OF_CONDUCT.md sur GitHub.

- -

Par exemple, les dépôts du MDN sont régis par les vastes Mozilla Community Participation Guidelines. Habituellement, un comportement légèrement offensant sur les dépôts MDN (comme le fait d'être constamment hors sujet/perturbant, ou d'être impoli) sera d'abord répondu par un avertissement sur le dépôt, suivi d'un dernier avertissement, puis d'un bannissement temporaire ou permanent. Les problèmes de comportement plus graves, tels que les discours haineux ou les menaces à l'encontre d'un autre contributeur, ne seront pas tolérés et entraîneront probablement un bannissement immédiat.

- -

Si vous recevez quelque chose qui vous met mal à l'aise, vous devez toujours le signaler en utilisant le mécanisme prévu dans le code de conduite.

- -

Choisissez des contributions percutantes

- -

Réfléchissez à ce que vous voulez faire sur le projet. Par exemple, nous avons une grande liste de problèmes déposés sur https://github.com/mdn/translated-content/issues, répartis selon diverses étiquettes GitHub en temps estimé de correction, catégories technologiques, et plus encore. Une autre bonne étiquette à rechercher est « good first issue », qui est généralement donnée aux issues qui sont assez simples et bonnes pour les débutants du projet pour commencer. Nous allons bientôt commencer à trier nos problèmes de manière plus approfondie, en ajoutant d'autres étiquettes telles que des indicateurs de priorité. Essayez de choisir quelques problèmes que vous pensez pouvoir gérer correctement avec le temps dont vous disposez, et demandez à y être affecté.

- -

Vous pouvez également contribuer en ouvrant des demandes de triage pour résoudre les problèmes que vous rencontrez en lisant les articles du site MDN.

- -

Une grande partie du travail sur le MDN consiste à rédiger de la documentation et des exemples de code, mais il existe d'autres façons de contribuer :

- - - -

Chaque correction est utile, aussi petite soit-elle, et nous n'en refuserons aucune. Cela dit, veillez à ce que vos corrections soient productives. Nous vous déconseillons ce genre de contributions :

- - - -

Dans de nombreux cas, les choses sont comme elles sont sur les OSP pour une raison. Vous devriez lire leurs guides de style, s'ils en ont un, et en cas de doute sur la productivité de quelque chose, demandez toujours avant !

- -

Suivez le guide

- -

Les bons OSP rendront toujours la documentation des contributeurs facilement accessible. Sur les projets GitHub, elle se trouve généralement dans le fichier CONTRIBUTING.md du dépôt, ou parfois dans le fichier README.md du projet. Étant un projet de documentation, le contenu de MDN dispose d'un README et d'un ensemble décent de docs pour les contributeurs sur le site lui-même (voir Contribuer à MDN).

- -

La seule chose à demander ici est de ne pas avoir peur de demander de l'aide, mais de TOUJOURS essayer de trouver la réponse à votre question avant de la poser. De cette façon, vous développez votre connaissance du projet et devenez plus indépendant, et vous n'imposez pas une charge inutile aux autres contributeurs.

- -

Bien sûr, la documentation ne sera pas toujours parfaite. Si vous trouvez quelque chose qui est difficile à trouver ou qui n'est pas très bien expliqué, déposez un ticket ou créez une demande de modification pour essayer de le corriger vous-même.

- -

Découvrez où poser des questions

- -

Cherchez toujours à savoir quel est le meilleur endroit pour poser des questions. Les bons OSP le préciseront toujours dans leur docs (voir Demander de l'aide sur le MDN). Si vous souhaitez poser des questions d'ordre général, utilisez toujours ces canaux. Ne vous contentez pas de déposer un ticket sur GitHub pour chaque question, car cela ajoute du poids au projet (voir "Faites des progrès, pas du bruit" ci-dessous).

- -

Faites des progrès, pas du bruit

- -

Réfléchissez bien à la façon dont vous gérez la communication dans le projet - assurez-vous qu'elle est utile et qu'elle ne complique pas le travail des autres contributeurs. Soumettre des pull requests pour corriger des bogues, c'est bien, mais sont-elles vraiment utiles et faciles à examiner ? Déposer des questions et participer à d'autres conversations, c'est bien, mais vos questions et commentaires sont-ils pertinents ou ne font-ils qu'ajouter du brouhaha ?

- -

En règle générale, faites ceci :

- - - -

Et pas :

- - - -

Les OSP sont une démocratie (ou presque)

- -

Les OSP sont assez démocratiques - de nombreuses décisions font l'objet d'un vote, et vous êtes largement libre de contribuer comme vous le souhaitez, tant que vous n'empêchez personne d'autre de contribuer.

- -

Cependant, certaines choses seront largement décidées par un petit groupe de contributeurs principaux. Vous êtes libre de vous opposer à toute décision, mais il arrive qu'un modérateur prenne une décision qui va à l'encontre de votre opinion. Vous devez respecter et accepter ces décisions.

- -

Il est utile d'apprendre à connaître les modérateurs d'un projet, afin de savoir à qui demander de l'aide, par exemple dans les fils de discussion des demandes de triage ou des problèmes.

- -

Soyez patient, soyez ponctuel

- -

Gardez à l'esprit que de nombreuses personnes travaillant sur des OSP le font sur leur temps libre, sans rémunération, et que toutes les personnes travaillant sur des OSP sont généralement très occupées. Si vous attendez quelque chose comme la révision d'une pull request ou une réponse à une question, soyez patient.

- -

Il est raisonnable d'attendre quelques jours, puis de demander poliment à quelqu'un s'il a eu le temps d'y jeter un coup d'œil, et éventuellement de relancer une semaine plus tard pour demander s'il est trop occupé pour le moment.

- -

Il n'est PAS raisonnable de commencer à exiger des choses, comme si on vous devait une réponse rapide. Ce n'est pas le cas.

- -

Si quelqu'un attend que vous fassiez quelque chose pour lui, vous devez faire preuve de la même courtoisie, mais en même temps, essayez de répondre aussi rapidement que possible. Si vous ne pouvez vraiment pas trouver le temps, faites-le savoir et demandez aux responsables de vous aider à trouver quelqu'un d'autre pour effectuer cette tâche.

- -

Voir aussi

- - diff --git a/files/fr/mdn/contribute/open_source_etiquette/index.md b/files/fr/mdn/contribute/open_source_etiquette/index.md new file mode 100644 index 0000000000..2721c7985c --- /dev/null +++ b/files/fr/mdn/contribute/open_source_etiquette/index.md @@ -0,0 +1,165 @@ +--- +title: Étiquette de base pour les projets open source +slug: MDN/Contribute/Open_source_etiquette +tags: + - Best practices + - Community + - Open source + - MDN + - Beginners +translation_of: MDN/Contribute/Open_source_etiquette +--- +

{{MDNSidebar}}

+ +

Si vous n'avez jamais travaillé sur un projet open source (OSP pour « Open Source Project ») auparavant, il est bon de lire cet article avant de commencer à contribuer à MDN (ou à d'autres projets open source). Il y a quelques bonnes pratiques à adopter qui vous permettront, à vous et aux autres contributrices et contributeurs du projet, de vous sentir valorisés et en sécurité, et de rester productifs.

+ +

Cet article ne vous apprendra pas tout ce qu'il faut savoir sur la contribution à un projet open source ; l'objectif est plutôt de vous donner quelques bons points de départ sur lesquels vous pourrez réfléchir et en apprendre davantage lorsque vous commencerez à contribuer à un projet open source.

+ +

Réfléchissez à la raison pour laquelle vous contribuez à un OSP

+ +

Avant de commencer à contribuer à un projet open source, demandez-vous pourquoi vous voulez le faire. Si la réponse à cette question est simplement « Je m'ennuie et je veux trouver quelque chose de productif à faire avec mon temps », c'est bien, mais vous pouvez probablement aller plus loin.

+ +

De meilleures raisons encore peuvent être envisagées :

+ +

+ +

Si vous passez votre temps à travailler gratuitement sur un projet, il est raisonnable de s'attendre à en retirer quelque chose. En fait, vous êtes beaucoup plus susceptible de rester plus longtemps et de contribuer de manière plus productive au projet. En outre, si vous avez un bon ensemble de raisons de contribuer avant de commencer, il sera plus facile de décider des tâches à entreprendre.

+ +

Voici quelques raisons pour lesquelles vous ne devriez pas commencer à contribuer :

+ + + +

Votre présence sur le projet doit rester productive, et ne pas empêcher les autres d'être productifs.

+ +

Soyez polis, soyez aimables, évitez les propos incendiaires ou offensants.

+ +

On pourrait abréger cela en disant « soyez gentil ». C'est le conseil numéro un que nous donnons à toute personne qui se lance dans les contributions open source.

+ +

Soyez gentil avec les autres contributeurs du projet, et le projet sera plus agréable et plus productif. Cela inclut :

+ + + +

Vous et les autres contributeurs êtes (ou devriez être) ici parce qu'ils veulent apporter une contribution positive au projet, mais au-delà de cela, vous ne pouvez rien présumer d'eux. Cela inclut leurs :

+ + + +

Vous devez donc vous en tenir autant que possible au sujet, en évitant les hors-sujets potentiellement controversés comme la religion ou la politique, et en faisant preuve de soutien et de respect même si vous n'êtes pas d'accord avec quelqu'un ou si vous n'aimez pas une décision qu'il a prise.

+ +

De même, vous devez vous abstenir de tout juron ou langage offensant sur MDN, même s'il n'est pas dirigé contre quelqu'un en particulier. Ce n'est pas nécessaire pour participer, et certaines personnes y sont vraiment sensibles.

+ +

Sachez qu'il existe des règles dans toute bonne OSP pour protéger ses contributeurs afin qu'ils ne se sentent pas mal à l'aise lorsqu'ils contribuent. Ces règles prennent généralement la forme d'un fichier CODE_OF_CONDUCT.md sur GitHub.

+ +

Par exemple, les dépôts du MDN sont régis par les vastes Mozilla Community Participation Guidelines. Habituellement, un comportement légèrement offensant sur les dépôts MDN (comme le fait d'être constamment hors sujet/perturbant, ou d'être impoli) sera d'abord répondu par un avertissement sur le dépôt, suivi d'un dernier avertissement, puis d'un bannissement temporaire ou permanent. Les problèmes de comportement plus graves, tels que les discours haineux ou les menaces à l'encontre d'un autre contributeur, ne seront pas tolérés et entraîneront probablement un bannissement immédiat.

+ +

Si vous recevez quelque chose qui vous met mal à l'aise, vous devez toujours le signaler en utilisant le mécanisme prévu dans le code de conduite.

+ +

Choisissez des contributions percutantes

+ +

Réfléchissez à ce que vous voulez faire sur le projet. Par exemple, nous avons une grande liste de problèmes déposés sur https://github.com/mdn/translated-content/issues, répartis selon diverses étiquettes GitHub en temps estimé de correction, catégories technologiques, et plus encore. Une autre bonne étiquette à rechercher est « good first issue », qui est généralement donnée aux issues qui sont assez simples et bonnes pour les débutants du projet pour commencer. Nous allons bientôt commencer à trier nos problèmes de manière plus approfondie, en ajoutant d'autres étiquettes telles que des indicateurs de priorité. Essayez de choisir quelques problèmes que vous pensez pouvoir gérer correctement avec le temps dont vous disposez, et demandez à y être affecté.

+ +

Vous pouvez également contribuer en ouvrant des demandes de triage pour résoudre les problèmes que vous rencontrez en lisant les articles du site MDN.

+ +

Une grande partie du travail sur le MDN consiste à rédiger de la documentation et des exemples de code, mais il existe d'autres façons de contribuer :

+ + + +

Chaque correction est utile, aussi petite soit-elle, et nous n'en refuserons aucune. Cela dit, veillez à ce que vos corrections soient productives. Nous vous déconseillons ce genre de contributions :

+ + + +

Dans de nombreux cas, les choses sont comme elles sont sur les OSP pour une raison. Vous devriez lire leurs guides de style, s'ils en ont un, et en cas de doute sur la productivité de quelque chose, demandez toujours avant !

+ +

Suivez le guide

+ +

Les bons OSP rendront toujours la documentation des contributeurs facilement accessible. Sur les projets GitHub, elle se trouve généralement dans le fichier CONTRIBUTING.md du dépôt, ou parfois dans le fichier README.md du projet. Étant un projet de documentation, le contenu de MDN dispose d'un README et d'un ensemble décent de docs pour les contributeurs sur le site lui-même (voir Contribuer à MDN).

+ +

La seule chose à demander ici est de ne pas avoir peur de demander de l'aide, mais de TOUJOURS essayer de trouver la réponse à votre question avant de la poser. De cette façon, vous développez votre connaissance du projet et devenez plus indépendant, et vous n'imposez pas une charge inutile aux autres contributeurs.

+ +

Bien sûr, la documentation ne sera pas toujours parfaite. Si vous trouvez quelque chose qui est difficile à trouver ou qui n'est pas très bien expliqué, déposez un ticket ou créez une demande de modification pour essayer de le corriger vous-même.

+ +

Découvrez où poser des questions

+ +

Cherchez toujours à savoir quel est le meilleur endroit pour poser des questions. Les bons OSP le préciseront toujours dans leur docs (voir Demander de l'aide sur le MDN). Si vous souhaitez poser des questions d'ordre général, utilisez toujours ces canaux. Ne vous contentez pas de déposer un ticket sur GitHub pour chaque question, car cela ajoute du poids au projet (voir "Faites des progrès, pas du bruit" ci-dessous).

+ +

Faites des progrès, pas du bruit

+ +

Réfléchissez bien à la façon dont vous gérez la communication dans le projet - assurez-vous qu'elle est utile et qu'elle ne complique pas le travail des autres contributeurs. Soumettre des pull requests pour corriger des bogues, c'est bien, mais sont-elles vraiment utiles et faciles à examiner ? Déposer des questions et participer à d'autres conversations, c'est bien, mais vos questions et commentaires sont-ils pertinents ou ne font-ils qu'ajouter du brouhaha ?

+ +

En règle générale, faites ceci :

+ + + +

Et pas :

+ + + +

Les OSP sont une démocratie (ou presque)

+ +

Les OSP sont assez démocratiques - de nombreuses décisions font l'objet d'un vote, et vous êtes largement libre de contribuer comme vous le souhaitez, tant que vous n'empêchez personne d'autre de contribuer.

+ +

Cependant, certaines choses seront largement décidées par un petit groupe de contributeurs principaux. Vous êtes libre de vous opposer à toute décision, mais il arrive qu'un modérateur prenne une décision qui va à l'encontre de votre opinion. Vous devez respecter et accepter ces décisions.

+ +

Il est utile d'apprendre à connaître les modérateurs d'un projet, afin de savoir à qui demander de l'aide, par exemple dans les fils de discussion des demandes de triage ou des problèmes.

+ +

Soyez patient, soyez ponctuel

+ +

Gardez à l'esprit que de nombreuses personnes travaillant sur des OSP le font sur leur temps libre, sans rémunération, et que toutes les personnes travaillant sur des OSP sont généralement très occupées. Si vous attendez quelque chose comme la révision d'une pull request ou une réponse à une question, soyez patient.

+ +

Il est raisonnable d'attendre quelques jours, puis de demander poliment à quelqu'un s'il a eu le temps d'y jeter un coup d'œil, et éventuellement de relancer une semaine plus tard pour demander s'il est trop occupé pour le moment.

+ +

Il n'est PAS raisonnable de commencer à exiger des choses, comme si on vous devait une réponse rapide. Ce n'est pas le cas.

+ +

Si quelqu'un attend que vous fassiez quelque chose pour lui, vous devez faire preuve de la même courtoisie, mais en même temps, essayez de répondre aussi rapidement que possible. Si vous ne pouvez vraiment pas trouver le temps, faites-le savoir et demandez aux responsables de vous aider à trouver quelqu'un d'autre pour effectuer cette tâche.

+ +

Voir aussi

+ + diff --git a/files/fr/mdn/contribute/processes/index.html b/files/fr/mdn/contribute/processes/index.html deleted file mode 100644 index ffc1cf92a3..0000000000 --- a/files/fr/mdn/contribute/processes/index.html +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Processus de documentation -slug: MDN/Contribute/Processes -tags: - - Landing - - MDN Meta - - Processes -translation_of: MDN/Contribute/Processes ---- -
{{MDNSidebar}}
- -

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.

- -

Vous pouvez également consulter les versions anglaises de ces pages pour les processus liés à la documentation en anglais.

- -

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/contribute/processes/index.md b/files/fr/mdn/contribute/processes/index.md new file mode 100644 index 0000000000..ffc1cf92a3 --- /dev/null +++ b/files/fr/mdn/contribute/processes/index.md @@ -0,0 +1,16 @@ +--- +title: Processus de documentation +slug: MDN/Contribute/Processes +tags: + - Landing + - MDN Meta + - Processes +translation_of: MDN/Contribute/Processes +--- +
{{MDNSidebar}}
+ +

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.

+ +

Vous pouvez également consulter les versions anglaises de ces pages pour les processus liés à la documentation en anglais.

+ +

{{LandingPageListSubPages()}}

diff --git a/files/fr/mdn/contribute/where_is_everything/index.html b/files/fr/mdn/contribute/where_is_everything/index.html deleted file mode 100644 index 349a70a3fb..0000000000 --- a/files/fr/mdn/contribute/where_is_everything/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Où se trouve tout sur MDN ? Un guide de nos dépôts -slug: MDN/Contribute/Where_is_everything -tags: - - Best practices - - Community - - GitHub - - MDN - - Beginners - - Repos -translation_of: MDN/Contribute/Where_is_everything ---- -

{{MDNSidebar}}

- -

MDN est un projet complexe avec de nombreux composants. Contribuer au site est facile au début, si vous avez quelques connaissances de GitHub et que vous commencez par corriger des fautes de frappe ou améliorer des extraits de code. Cependant, lorsque vous commencez à faire des contributions plus importantes, comme l'ajout de nouvelles pages entières, vous remarquerez que de nombreux éléments du contenu ne sont pas stockés dans les sources de la page et proviennent d'ailleurs.

- -

Cet article sert de guide rapide pour trouver les différents dépôts que vous devez modifier pour mettre à jour les différentes parties du contenu de MDN.

- -

Dépôts principaux

- - - -

Autres dépôts

- - diff --git a/files/fr/mdn/contribute/where_is_everything/index.md b/files/fr/mdn/contribute/where_is_everything/index.md new file mode 100644 index 0000000000..349a70a3fb --- /dev/null +++ b/files/fr/mdn/contribute/where_is_everything/index.md @@ -0,0 +1,35 @@ +--- +title: Où se trouve tout sur MDN ? Un guide de nos dépôts +slug: MDN/Contribute/Where_is_everything +tags: + - Best practices + - Community + - GitHub + - MDN + - Beginners + - Repos +translation_of: MDN/Contribute/Where_is_everything +--- +

{{MDNSidebar}}

+ +

MDN est un projet complexe avec de nombreux composants. Contribuer au site est facile au début, si vous avez quelques connaissances de GitHub et que vous commencez par corriger des fautes de frappe ou améliorer des extraits de code. Cependant, lorsque vous commencez à faire des contributions plus importantes, comme l'ajout de nouvelles pages entières, vous remarquerez que de nombreux éléments du contenu ne sont pas stockés dans les sources de la page et proviennent d'ailleurs.

+ +

Cet article sert de guide rapide pour trouver les différents dépôts que vous devez modifier pour mettre à jour les différentes parties du contenu de MDN.

+ +

Dépôts principaux

+ + + +

Autres dépôts

+ + diff --git a/files/fr/mdn/guidelines/code_guidelines/css/index.html b/files/fr/mdn/guidelines/code_guidelines/css/index.html deleted file mode 100644 index 2e2a768762..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/css/index.html +++ /dev/null @@ -1,255 +0,0 @@ ---- -title: Lignes directrices du CSS -slug: MDN/Guidelines/Code_guidelines/CSS -tags: - - CSS - - Code - - Guide - - Directives - - MDN Meta -translation_of: MDN/Guidelines/Code_guidelines/CSS ---- -
{{MDNSidebar}}
- -

Les directives suivantes couvrent la manière d'écrire les CSS pour les exemples de code MDN.

- -

Dans cet article

- - - -

Lignes directrices de haut niveau

- -

N'utilisez pas de préprocesseurs

- -

N'utilisez pas la syntaxe des préprocesseurs, ex. Sass, Less, ou Stylus, dans votre code d'exemple MDN. MDN documente le langage CSS classique, et l'utilisation de préprocesseurs ne sert qu'à élever la barre pour comprendre les exemples, ce qui peut potentiellement perdre les lecteurs.

- -

N'utilisez pas de méthodologies CSS spécifiques

- -

Dans le même esprit que la directive précédente, n'écrivez pas de code d'exemple MDN en utilisant une méthodologie CSS spécifique telle que BEM ou SMACSS. Même s'il s'agit de syntaxe CSS valide, les conventions de dénomination peuvent prêter à confusion pour les personnes qui ne sont pas familières avec ces méthodologies.

- -

Utiliser des unités flexibles/relatives

- -

Pour une flexibilité maximale sur le plus grand nombre possible d'appareils, il est judicieux de dimensionner les conteneurs, le padding, etc. en utilisant des unités relatives comme les em et les rem, ou des pourcentages et des unités de « viewport » si vous souhaitez qu'ils varient en fonction de la largeur du « viewport ». Vous pouvez en savoir plus à ce sujet dans notre article Éléments de construction d'un design adaptatif (Responsive Design).

- -

Ne pas utiliser de réinitialisation

- -

Pour un contrôle maximal des CSS sur toutes les plates-formes, beaucoup de gens avaient l'habitude d'utiliser les réinitialisations CSS pour supprimer tous les styles, avant de reconstruire les choses eux-mêmes. Cette méthode a certainement ses mérites, mais surtout dans le monde moderne, les réinitialisations CSS peuvent être excessives et entraîner beaucoup de temps supplémentaire passé à réimplémenter des choses qui n'étaient pas complètement cassées au départ, comme les marges par défaut, les styles de liste, etc.

- -

Si vous avez vraiment envie d'utiliser une réinitialisation, envisagez d'utiliser normalize.css de Nicolas Gallagher, qui vise simplement à rendre les choses plus cohérentes d'un navigateur à l'autre, à se débarrasser de certains désagréments par défaut que nous supprimons toujours (les marges sur <body>, par exemple) et à corriger quelques bogues.

- -

Planifiez votre CSS — évitez les surcharges

- -

Avant de vous lancer dans l'écriture de gros morceaux de CSS, planifiez soigneusement vos styles. Quels styles généraux seront nécessaires, quelles mises en page différentes devrez-vous créer, quelles redéfinitions spécifiques devront être créées et seront-elles réutilisables ? Par-dessus tout, vous devez essayer d'éviter de créer trop de redéfinitions. Si vous vous retrouvez constamment en train d'écrire des styles pour ensuite les annuler quelques règles plus bas, vous devez probablement repenser votre stratégie.

- -

Style général de codage CSS

- -

Utiliser une syntaxe étendue

- -

Vous pouvez utiliser différents styles d'écriture CSS, mais nous préférons le style étendu, avec le sélecteur/l'accolade ouvrante, l'accolade fermante et chaque déclaration sur une ligne distincte. Cela optimise la lisibilité et favorise la cohérence sur le MDN.

- -

Utilisez ceci :

- -
p {
-  color: white;
-  background-color: black;
-  padding: 1rem;
-}
- -

Pas cela :

- -
p { color: white; background-color: black; padding: 1rem; }
- -

En outre, gardez ces spécificités à l'esprit :

- - - -

Privilégiez les règles longues aux règles raccourcies

- -

En général, lorsque vous enseignez les spécificités de la syntaxe CSS, il est plus clair et plus évident d'utiliser des propriétés longues plutôt que des raccourcies (à moins bien sûr que l'enseignement du raccourci ne soit le but de l'exemple). N'oubliez pas que les exemples du MDN ont pour but d'enseigner aux gens, et non d'être efficaces ou astucieuses.

- -

Tout d'abord, il est souvent plus difficile de comprendre ce que fait le raccourci. Il faut un certain temps pour comprendre exactement ce que fait la syntaxe font, par exemple :

- -
font: small-caps bold 2rem/1.5 sans-serif;
- -

Alors que celle-ci est plus immédiate en termes de compréhension :

- -
font-variant: small-caps;
-font-weight: bold;
-font-size: 2rem;
-line-height: 1.5;
-font-family: sans-serif;
- -

Deuxièmement, les raccourcis CSS comportent des pièges potentiels supplémentaires : des valeurs par défaut sont définies pour des parties de la syntaxe que vous n'avez pas explicitement définies, ce qui peut produire des réinitialisations inattendues des valeurs que vous avez définies plus tôt dans la cascade, ou d'autres effets attendus. Par exemple, la propriété grid définit toutes les valeurs par défaut suivantes pour les éléments qui ne sont pas spécifiés :

- - - -

En outre, certains raccourcis ne fonctionnent comme prévu que si vous incluez les différents composants de la valeur dans un certain ordre. Dans les animations CSS, par exemple :

- -
/* duration | timing-function | delay | iteration-count
-   direction | fill-mode | play-state | name */
-animation: 3s ease-in 1s 2 reverse both paused slidein;
- -

À titre d'exemple, la première valeur qui peut être analysée comme un <time> est affecté à la propriété animation-duration, et la seconde est affectée à animation-delay. Pour plus de détails, lisez l'intégralité de syntaxe de l'animation.

- -

Utilisez des guillemets doubles autour des valeurs

- -

Lorsque des guillemets peuvent ou doivent être inclus, utilisez-les, et utilisez des guillemets doubles. Par exemple :

- -
[data-vegetable="liquid"] {
-  background-color: goldenrod;
-  background-image: url("../../media/examples/lizard.png");
-}
- -

Espacement autour des paramètres de la fonction

- -

Les paramètres des fonctions doivent comporter des espaces après les virgules de séparation, mais pas avant :

- -
color: rgb(255, 0, 0);
-background-image: linear-gradient(to bottom, red, black);
- -

Commentaires CSS

- -

Utilisez des commentaires de style CSS pour commenter le code qui n'est pas auto-documenté :

- -
/* Il s'agit d'un commentaire de style CSS */
- -

Mettez vos commentaires sur des lignes séparées précédant le code auquel ils se réfèrent :

- -
h3 {
-  /* Crée une ombre portée rouge, décalée de 1px vers la droite et le bas, avec un rayon de flou de 2px. */
-  text-shadow: 1px 1px 2px red;
-  /* Définit la taille de la police au double de la taille de la police du document par défaut. */
-  font-size: 2rem;
-}
- -

Notez également que vous devez laisser un espace entre les astérisques et le commentaire, dans chaque cas.

- -

Ne pas utiliser !important

- -

!important est un dernier recours généralement utilisé uniquement lorsque vous devez remplacer quelque chose et qu'il n'y a pas d'autre moyen. Il s'agit d'une mauvaise pratique que vous devez éviter dans la mesure du possible.

- -

Mauvais usage :

- -
.bad-code {
-  font-size: 4rem !important;
-}
- -

Points de syntaxe CSS spécifiques

- -

Désactiver les bordures et autres propriétés

- -

Lorsque vous désactivez les bordures (et toute autre propriété qui peut prendre 0 ou none comme valeurs), utilisez 0 plutôt que none :

- -
border: 0;
- -

Utilisez des requêtes média "mobile first"

- -

Lorsque vous incluez différents ensembles de styles pour différentes tailles de fenêtres d'affichage à l'aide de requêtes de médias dans la même feuille de style, il est judicieux de faire en sorte que le style par défaut avant l'application de toute requête de médias au document soit le style pour écran étroit/mobile, puis de le remplacer pour les fenêtres d'affichage plus larges dans des requêtes de médias successives.

- -
/* Mise en page CSS par défaut pour les écrans étroits */
-
-@media (min-width: 480px) {
-  /* CSS pour les écrans de largeur moyenne */
-}
-
-@media (min-width: 800px) {
-  /* CSS pour les écrans larges */
-}
-
-@media (min-width: 1100px) {
-  /* CSS pour les écrans très larges */
-}
- -

Cela présente de nombreux avantages, exposés dans notre article Priorité aux mobiles.

- -

Sélecteurs

- -

N'utilisez pas de sélecteurs ID

- -

Il n'est pas vraiment nécessaire d'utiliser des sélecteurs d'ID - ils sont moins flexibles (vous ne pouvez pas en ajouter d'autres si vous découvrez que vous en avez besoin de plus d'un), et il est plus difficile de les remplacer si nécessaire, car ils sont plus spécifiques que les classes.

- -

Bonne pratique :

- -
.editorial-summary {
-  ...
-}
- -

Mauvaise pratique :

- -
#editorial-summary {
-  ...
-}
- -

Mettre les sélecteurs multiples sur des lignes séparées

- -

Lorsqu'une règle comporte plusieurs sélecteurs, placez chaque sélecteur sur une nouvelle ligne. La liste des sélecteurs est ainsi plus facile à lire et les lignes de code sont plus courtes.

- -

Faites ceci :

- -
h1,
-h2,
-h3 {
-  font-family: sans-serif;
-  text-align: center;
-}
- -

Pas ça :

- -
h1, h2, h3 {
-  font-family: sans-serif;
-  text-align: center;
-}
- -

De bons exemples de CSS sur MDN

- -

Vous pouvez trouver de bons extraits CSS concis et significatifs en haut de nos pages de référence des propriétés CSS - parcourez notre index des mots-clés CSS pour en trouver. Nos exemples interactifs sont généralement écrits pour suivre les directives ci-dessus, mais sachez qu'ils peuvent différer à certains endroits, car ils ont pour la plupart été écrits avant la nouvelle rédaction des directives.

diff --git a/files/fr/mdn/guidelines/code_guidelines/css/index.md b/files/fr/mdn/guidelines/code_guidelines/css/index.md new file mode 100644 index 0000000000..2e2a768762 --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/css/index.md @@ -0,0 +1,255 @@ +--- +title: Lignes directrices du CSS +slug: MDN/Guidelines/Code_guidelines/CSS +tags: + - CSS + - Code + - Guide + - Directives + - MDN Meta +translation_of: MDN/Guidelines/Code_guidelines/CSS +--- +
{{MDNSidebar}}
+ +

Les directives suivantes couvrent la manière d'écrire les CSS pour les exemples de code MDN.

+ +

Dans cet article

+ + + +

Lignes directrices de haut niveau

+ +

N'utilisez pas de préprocesseurs

+ +

N'utilisez pas la syntaxe des préprocesseurs, ex. Sass, Less, ou Stylus, dans votre code d'exemple MDN. MDN documente le langage CSS classique, et l'utilisation de préprocesseurs ne sert qu'à élever la barre pour comprendre les exemples, ce qui peut potentiellement perdre les lecteurs.

+ +

N'utilisez pas de méthodologies CSS spécifiques

+ +

Dans le même esprit que la directive précédente, n'écrivez pas de code d'exemple MDN en utilisant une méthodologie CSS spécifique telle que BEM ou SMACSS. Même s'il s'agit de syntaxe CSS valide, les conventions de dénomination peuvent prêter à confusion pour les personnes qui ne sont pas familières avec ces méthodologies.

+ +

Utiliser des unités flexibles/relatives

+ +

Pour une flexibilité maximale sur le plus grand nombre possible d'appareils, il est judicieux de dimensionner les conteneurs, le padding, etc. en utilisant des unités relatives comme les em et les rem, ou des pourcentages et des unités de « viewport » si vous souhaitez qu'ils varient en fonction de la largeur du « viewport ». Vous pouvez en savoir plus à ce sujet dans notre article Éléments de construction d'un design adaptatif (Responsive Design).

+ +

Ne pas utiliser de réinitialisation

+ +

Pour un contrôle maximal des CSS sur toutes les plates-formes, beaucoup de gens avaient l'habitude d'utiliser les réinitialisations CSS pour supprimer tous les styles, avant de reconstruire les choses eux-mêmes. Cette méthode a certainement ses mérites, mais surtout dans le monde moderne, les réinitialisations CSS peuvent être excessives et entraîner beaucoup de temps supplémentaire passé à réimplémenter des choses qui n'étaient pas complètement cassées au départ, comme les marges par défaut, les styles de liste, etc.

+ +

Si vous avez vraiment envie d'utiliser une réinitialisation, envisagez d'utiliser normalize.css de Nicolas Gallagher, qui vise simplement à rendre les choses plus cohérentes d'un navigateur à l'autre, à se débarrasser de certains désagréments par défaut que nous supprimons toujours (les marges sur <body>, par exemple) et à corriger quelques bogues.

+ +

Planifiez votre CSS — évitez les surcharges

+ +

Avant de vous lancer dans l'écriture de gros morceaux de CSS, planifiez soigneusement vos styles. Quels styles généraux seront nécessaires, quelles mises en page différentes devrez-vous créer, quelles redéfinitions spécifiques devront être créées et seront-elles réutilisables ? Par-dessus tout, vous devez essayer d'éviter de créer trop de redéfinitions. Si vous vous retrouvez constamment en train d'écrire des styles pour ensuite les annuler quelques règles plus bas, vous devez probablement repenser votre stratégie.

+ +

Style général de codage CSS

+ +

Utiliser une syntaxe étendue

+ +

Vous pouvez utiliser différents styles d'écriture CSS, mais nous préférons le style étendu, avec le sélecteur/l'accolade ouvrante, l'accolade fermante et chaque déclaration sur une ligne distincte. Cela optimise la lisibilité et favorise la cohérence sur le MDN.

+ +

Utilisez ceci :

+ +
p {
+  color: white;
+  background-color: black;
+  padding: 1rem;
+}
+ +

Pas cela :

+ +
p { color: white; background-color: black; padding: 1rem; }
+ +

En outre, gardez ces spécificités à l'esprit :

+ + + +

Privilégiez les règles longues aux règles raccourcies

+ +

En général, lorsque vous enseignez les spécificités de la syntaxe CSS, il est plus clair et plus évident d'utiliser des propriétés longues plutôt que des raccourcies (à moins bien sûr que l'enseignement du raccourci ne soit le but de l'exemple). N'oubliez pas que les exemples du MDN ont pour but d'enseigner aux gens, et non d'être efficaces ou astucieuses.

+ +

Tout d'abord, il est souvent plus difficile de comprendre ce que fait le raccourci. Il faut un certain temps pour comprendre exactement ce que fait la syntaxe font, par exemple :

+ +
font: small-caps bold 2rem/1.5 sans-serif;
+ +

Alors que celle-ci est plus immédiate en termes de compréhension :

+ +
font-variant: small-caps;
+font-weight: bold;
+font-size: 2rem;
+line-height: 1.5;
+font-family: sans-serif;
+ +

Deuxièmement, les raccourcis CSS comportent des pièges potentiels supplémentaires : des valeurs par défaut sont définies pour des parties de la syntaxe que vous n'avez pas explicitement définies, ce qui peut produire des réinitialisations inattendues des valeurs que vous avez définies plus tôt dans la cascade, ou d'autres effets attendus. Par exemple, la propriété grid définit toutes les valeurs par défaut suivantes pour les éléments qui ne sont pas spécifiés :

+ + + +

En outre, certains raccourcis ne fonctionnent comme prévu que si vous incluez les différents composants de la valeur dans un certain ordre. Dans les animations CSS, par exemple :

+ +
/* duration | timing-function | delay | iteration-count
+   direction | fill-mode | play-state | name */
+animation: 3s ease-in 1s 2 reverse both paused slidein;
+ +

À titre d'exemple, la première valeur qui peut être analysée comme un <time> est affecté à la propriété animation-duration, et la seconde est affectée à animation-delay. Pour plus de détails, lisez l'intégralité de syntaxe de l'animation.

+ +

Utilisez des guillemets doubles autour des valeurs

+ +

Lorsque des guillemets peuvent ou doivent être inclus, utilisez-les, et utilisez des guillemets doubles. Par exemple :

+ +
[data-vegetable="liquid"] {
+  background-color: goldenrod;
+  background-image: url("../../media/examples/lizard.png");
+}
+ +

Espacement autour des paramètres de la fonction

+ +

Les paramètres des fonctions doivent comporter des espaces après les virgules de séparation, mais pas avant :

+ +
color: rgb(255, 0, 0);
+background-image: linear-gradient(to bottom, red, black);
+ +

Commentaires CSS

+ +

Utilisez des commentaires de style CSS pour commenter le code qui n'est pas auto-documenté :

+ +
/* Il s'agit d'un commentaire de style CSS */
+ +

Mettez vos commentaires sur des lignes séparées précédant le code auquel ils se réfèrent :

+ +
h3 {
+  /* Crée une ombre portée rouge, décalée de 1px vers la droite et le bas, avec un rayon de flou de 2px. */
+  text-shadow: 1px 1px 2px red;
+  /* Définit la taille de la police au double de la taille de la police du document par défaut. */
+  font-size: 2rem;
+}
+ +

Notez également que vous devez laisser un espace entre les astérisques et le commentaire, dans chaque cas.

+ +

Ne pas utiliser !important

+ +

!important est un dernier recours généralement utilisé uniquement lorsque vous devez remplacer quelque chose et qu'il n'y a pas d'autre moyen. Il s'agit d'une mauvaise pratique que vous devez éviter dans la mesure du possible.

+ +

Mauvais usage :

+ +
.bad-code {
+  font-size: 4rem !important;
+}
+ +

Points de syntaxe CSS spécifiques

+ +

Désactiver les bordures et autres propriétés

+ +

Lorsque vous désactivez les bordures (et toute autre propriété qui peut prendre 0 ou none comme valeurs), utilisez 0 plutôt que none :

+ +
border: 0;
+ +

Utilisez des requêtes média "mobile first"

+ +

Lorsque vous incluez différents ensembles de styles pour différentes tailles de fenêtres d'affichage à l'aide de requêtes de médias dans la même feuille de style, il est judicieux de faire en sorte que le style par défaut avant l'application de toute requête de médias au document soit le style pour écran étroit/mobile, puis de le remplacer pour les fenêtres d'affichage plus larges dans des requêtes de médias successives.

+ +
/* Mise en page CSS par défaut pour les écrans étroits */
+
+@media (min-width: 480px) {
+  /* CSS pour les écrans de largeur moyenne */
+}
+
+@media (min-width: 800px) {
+  /* CSS pour les écrans larges */
+}
+
+@media (min-width: 1100px) {
+  /* CSS pour les écrans très larges */
+}
+ +

Cela présente de nombreux avantages, exposés dans notre article Priorité aux mobiles.

+ +

Sélecteurs

+ +

N'utilisez pas de sélecteurs ID

+ +

Il n'est pas vraiment nécessaire d'utiliser des sélecteurs d'ID - ils sont moins flexibles (vous ne pouvez pas en ajouter d'autres si vous découvrez que vous en avez besoin de plus d'un), et il est plus difficile de les remplacer si nécessaire, car ils sont plus spécifiques que les classes.

+ +

Bonne pratique :

+ +
.editorial-summary {
+  ...
+}
+ +

Mauvaise pratique :

+ +
#editorial-summary {
+  ...
+}
+ +

Mettre les sélecteurs multiples sur des lignes séparées

+ +

Lorsqu'une règle comporte plusieurs sélecteurs, placez chaque sélecteur sur une nouvelle ligne. La liste des sélecteurs est ainsi plus facile à lire et les lignes de code sont plus courtes.

+ +

Faites ceci :

+ +
h1,
+h2,
+h3 {
+  font-family: sans-serif;
+  text-align: center;
+}
+ +

Pas ça :

+ +
h1, h2, h3 {
+  font-family: sans-serif;
+  text-align: center;
+}
+ +

De bons exemples de CSS sur MDN

+ +

Vous pouvez trouver de bons extraits CSS concis et significatifs en haut de nos pages de référence des propriétés CSS - parcourez notre index des mots-clés CSS pour en trouver. Nos exemples interactifs sont généralement écrits pour suivre les directives ci-dessus, mais sachez qu'ils peuvent différer à certains endroits, car ils ont pour la plupart été écrits avant la nouvelle rédaction des directives.

diff --git a/files/fr/mdn/guidelines/code_guidelines/general/index.html b/files/fr/mdn/guidelines/code_guidelines/general/index.html deleted file mode 100644 index d35985d1aa..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/general/index.html +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: Lignes directrices générales pour tous les exemples de code -slug: MDN/Guidelines/Code_guidelines/General -tags: - - Code - - General - - Guide - - Directives - - MDN Meta -translation_of: MDN/Guidelines/Code_guidelines/General ---- -
{{MDNSidebar}}
- -

Les directives suivantes concernant les exemples de code s'appliquent à tout le code, qu'il s'agisse de HTML, de CSS, de JavaScript ou d'autre chose.

- -

Dans cet article

- - - -

Indentation, espacement, taille

- -

Indentation

- -

Tout le code doit utiliser 2 espaces pour l'indentation, par exemple :

- -
<div>
-  <p>C'est mon paragraphe.</p>
-</div>
- -
function myFunc() {
-  if(thingy) {
-    console.log('Ouaip, ça a marché.');
-  }
-}
- -

Longueur des lignes de code

- -

Les lignes de code ne doivent pas comporter plus de 80 caractères (64 pour les exemples interactifs). Vous devez rompre les lignes de manière raisonnable pour des raisons de lisibilité, mais pas au détriment des bonnes pratiques.

- -

Par exemple, ceci n'est pas génial :

- -
let tommyCat = 'Dit Tommy le chat en reculant pour évacuer tout corps étranger qui aurait pu se loger dans sa puissante gorge. Plus d'un gros rat de gouttière avait trouvé la mort en regardant à bout portant le canon caverneux de cette impressionnante machine à rôder.';
- -

C'est mieux, mais un peu gênant :

- -
let tommyCat = 'Dit Tommy le chat en reculant pour évacuer tout corps étranger '
-+ 'qui aurait pu se loger dans sa puissante gorge. Plus d’un gros rat de gouttière '
-+ 'avait trouvé la mort en regardant à bout portant le canon caverneux de cette '
-+ 'impressionnante machine à rôder.';
- -

Une meilleure solution consiste à utiliser un template :

- -
let tommyCat = `Dit Tommy le chat en reculant pour évacuer tout corps étranger
-  qui aurait pu se loger dans sa puissante gorge. Plus d'un gros rat de gouttière
-  avait trouvé la mort en regardant à bout portant le canon caverneux de cette
-  impressionnante machine à rôder.`;
- -

Hauteur des blocs de code

- -

Les blocs de code doivent être aussi longs que nécessaire, mais pas plus. L'idéal est de viser quelque chose de court, comme 15 à 25 lignes. Si un bloc de code doit être beaucoup plus long, envisagez de ne montrer que l'extrait le plus utile et de créer un lien vers l'exemple complet sur un repo GitHub ou un CodePen, par exemple.

- -

Directives pour l'affichage des exemples

- -

Taille du rendu des exemples

- -

Le volet de contenu principal de MDN a une largeur d'environ 700px sur un ordinateur de bureau. Les exemples intégrés à MDN doivent donc avoir une apparence correcte à cette largeur (définissez la largeur des exemples intégrés à 100%).

- -

En ce qui concerne la hauteur, nous vous recommandons de maintenir l'exemple rendu à moins de 700px de hauteur si possible, pour une lisibilité maximale à l'écran.

- -

Vous devriez également penser à rendre vos exemples plus ou moins adaptables, afin qu'ils soient également utiles sur les appareils mobiles.

- -

Utilisation d'images et d'autres médias

- -

Parfois, vous voudrez inclure des images ou d'autres médias dans un exemple. Si vous le faites :

- - - -

Utilisation de la couleur

- -

Minuscule pour l'hexadécimal, peut utiliser des mots-clés pour les nuances et les couleurs primaires (ex. : black, white, red), utiliser des schémas plus complexes uniquement si nécessaire (ex. : pour inclure la transparence).

- -

Préférez utiliser des mots-clés pour les couleurs primaires et autres couleurs "de base", par exemple :

- -
-color: black;
-color: white;
-color: red;
-
- -

Utilisez rgb() pour des couleurs plus complexes (y compris les couleurs semi-transparentes) :

- -
-color: rgb(0, 0, 0, 0.5);
-color: rgb(248, 242, 230);
-
- -

Si vous devez utiliser des couleurs hexadécimales, utilisez des minuscules :

- -
-color: #058ed9;
-color: #a39a92;
-
- -

et utilisez la forme abrégée le cas échéant :

- -
-color: #ff0;
-color: #fff;
-
- -

Le fichier sass/vars/_color-palette.scss du dépôt mdn-minimalist comporte un ensemble de couleurs utiles qui complètent le design général de MDN.

- -

Mettre en évidence les exemples de bonnes et de mauvaises pratiques

- -

Comme vous le remarquerez en parcourant ces lignes directrices, les blocs de code censés être des exemples de bonnes pratiques sont marqués d'un fond en vert, et les blocs de code censés être des exemples de mauvaises pratiques sont marqués d'un fond en rouge.

- -

Pour ce faire, vous devez d'abord utiliser les commandes de l'éditeur MDN pour placer votre bloc de code dans un bloc <pre> et lui donner la coloration syntaxique appropriée. La source du code ressemblera à quelque chose comme ceci :

- -
-function myFunc() {
-  console.log('Hello!');
-};
-</pre>
-
- -

Pour en faire un bon exemple, vous insérez example-good juste avant le guillemet fermant de l'attribut class :

- -
<pre class="brush: js example-good">
-  ...
-
- -

Pour en faire un mauvais exemple, vous insérez example-bad juste avant le guillemet fermant de l'attribut class :

- -
<pre class="brush: js example-bad">
-  ...
-
- -

Nous aimerions vous encourager à les utiliser. Il n'est pas nécessaire de les utiliser partout, mais seulement lorsque vous signalez spécifiquement les bonnes et mauvaises pratiques dans votre code.

- -

Rédaction de sections syntaxiques sur les pages de référence

- -

Les pages de référence MDN comprennent des sections Syntaxe qui indiquent sans ambiguïté quelle peut/doit être la syntaxe d'une fonctionnalité, par exemple une méthode JavaScript, une propriété CSS, un élément HTML, etc. Des directives pour les rédiger sont données sur le document Sections syntaxiques.

diff --git a/files/fr/mdn/guidelines/code_guidelines/general/index.md b/files/fr/mdn/guidelines/code_guidelines/general/index.md new file mode 100644 index 0000000000..d35985d1aa --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/general/index.md @@ -0,0 +1,167 @@ +--- +title: Lignes directrices générales pour tous les exemples de code +slug: MDN/Guidelines/Code_guidelines/General +tags: + - Code + - General + - Guide + - Directives + - MDN Meta +translation_of: MDN/Guidelines/Code_guidelines/General +--- +
{{MDNSidebar}}
+ +

Les directives suivantes concernant les exemples de code s'appliquent à tout le code, qu'il s'agisse de HTML, de CSS, de JavaScript ou d'autre chose.

+ +

Dans cet article

+ + + +

Indentation, espacement, taille

+ +

Indentation

+ +

Tout le code doit utiliser 2 espaces pour l'indentation, par exemple :

+ +
<div>
+  <p>C'est mon paragraphe.</p>
+</div>
+ +
function myFunc() {
+  if(thingy) {
+    console.log('Ouaip, ça a marché.');
+  }
+}
+ +

Longueur des lignes de code

+ +

Les lignes de code ne doivent pas comporter plus de 80 caractères (64 pour les exemples interactifs). Vous devez rompre les lignes de manière raisonnable pour des raisons de lisibilité, mais pas au détriment des bonnes pratiques.

+ +

Par exemple, ceci n'est pas génial :

+ +
let tommyCat = 'Dit Tommy le chat en reculant pour évacuer tout corps étranger qui aurait pu se loger dans sa puissante gorge. Plus d'un gros rat de gouttière avait trouvé la mort en regardant à bout portant le canon caverneux de cette impressionnante machine à rôder.';
+ +

C'est mieux, mais un peu gênant :

+ +
let tommyCat = 'Dit Tommy le chat en reculant pour évacuer tout corps étranger '
++ 'qui aurait pu se loger dans sa puissante gorge. Plus d’un gros rat de gouttière '
++ 'avait trouvé la mort en regardant à bout portant le canon caverneux de cette '
++ 'impressionnante machine à rôder.';
+ +

Une meilleure solution consiste à utiliser un template :

+ +
let tommyCat = `Dit Tommy le chat en reculant pour évacuer tout corps étranger
+  qui aurait pu se loger dans sa puissante gorge. Plus d'un gros rat de gouttière
+  avait trouvé la mort en regardant à bout portant le canon caverneux de cette
+  impressionnante machine à rôder.`;
+ +

Hauteur des blocs de code

+ +

Les blocs de code doivent être aussi longs que nécessaire, mais pas plus. L'idéal est de viser quelque chose de court, comme 15 à 25 lignes. Si un bloc de code doit être beaucoup plus long, envisagez de ne montrer que l'extrait le plus utile et de créer un lien vers l'exemple complet sur un repo GitHub ou un CodePen, par exemple.

+ +

Directives pour l'affichage des exemples

+ +

Taille du rendu des exemples

+ +

Le volet de contenu principal de MDN a une largeur d'environ 700px sur un ordinateur de bureau. Les exemples intégrés à MDN doivent donc avoir une apparence correcte à cette largeur (définissez la largeur des exemples intégrés à 100%).

+ +

En ce qui concerne la hauteur, nous vous recommandons de maintenir l'exemple rendu à moins de 700px de hauteur si possible, pour une lisibilité maximale à l'écran.

+ +

Vous devriez également penser à rendre vos exemples plus ou moins adaptables, afin qu'ils soient également utiles sur les appareils mobiles.

+ +

Utilisation d'images et d'autres médias

+ +

Parfois, vous voudrez inclure des images ou d'autres médias dans un exemple. Si vous le faites :

+ + + +

Utilisation de la couleur

+ +

Minuscule pour l'hexadécimal, peut utiliser des mots-clés pour les nuances et les couleurs primaires (ex. : black, white, red), utiliser des schémas plus complexes uniquement si nécessaire (ex. : pour inclure la transparence).

+ +

Préférez utiliser des mots-clés pour les couleurs primaires et autres couleurs "de base", par exemple :

+ +
+color: black;
+color: white;
+color: red;
+
+ +

Utilisez rgb() pour des couleurs plus complexes (y compris les couleurs semi-transparentes) :

+ +
+color: rgb(0, 0, 0, 0.5);
+color: rgb(248, 242, 230);
+
+ +

Si vous devez utiliser des couleurs hexadécimales, utilisez des minuscules :

+ +
+color: #058ed9;
+color: #a39a92;
+
+ +

et utilisez la forme abrégée le cas échéant :

+ +
+color: #ff0;
+color: #fff;
+
+ +

Le fichier sass/vars/_color-palette.scss du dépôt mdn-minimalist comporte un ensemble de couleurs utiles qui complètent le design général de MDN.

+ +

Mettre en évidence les exemples de bonnes et de mauvaises pratiques

+ +

Comme vous le remarquerez en parcourant ces lignes directrices, les blocs de code censés être des exemples de bonnes pratiques sont marqués d'un fond en vert, et les blocs de code censés être des exemples de mauvaises pratiques sont marqués d'un fond en rouge.

+ +

Pour ce faire, vous devez d'abord utiliser les commandes de l'éditeur MDN pour placer votre bloc de code dans un bloc <pre> et lui donner la coloration syntaxique appropriée. La source du code ressemblera à quelque chose comme ceci :

+ +
+function myFunc() {
+  console.log('Hello!');
+};
+</pre>
+
+ +

Pour en faire un bon exemple, vous insérez example-good juste avant le guillemet fermant de l'attribut class :

+ +
<pre class="brush: js example-good">
+  ...
+
+ +

Pour en faire un mauvais exemple, vous insérez example-bad juste avant le guillemet fermant de l'attribut class :

+ +
<pre class="brush: js example-bad">
+  ...
+
+ +

Nous aimerions vous encourager à les utiliser. Il n'est pas nécessaire de les utiliser partout, mais seulement lorsque vous signalez spécifiquement les bonnes et mauvaises pratiques dans votre code.

+ +

Rédaction de sections syntaxiques sur les pages de référence

+ +

Les pages de référence MDN comprennent des sections Syntaxe qui indiquent sans ambiguïté quelle peut/doit être la syntaxe d'une fonctionnalité, par exemple une méthode JavaScript, une propriété CSS, un élément HTML, etc. Des directives pour les rédiger sont données sur le document Sections syntaxiques.

diff --git a/files/fr/mdn/guidelines/code_guidelines/html/index.html b/files/fr/mdn/guidelines/code_guidelines/html/index.html deleted file mode 100644 index 086c1f5e34..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/html/index.html +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: Lignes directrices pour le HTML -slug: MDN/Guidelines/Code_guidelines/HTML -tags: - - Code - - Guide - - Directives - - HTML - - MDN Meta -translation_of: MDN/Guidelines/Code_guidelines/HTML ---- -
{{MDNSidebar}}
- -

Les directives suivantes couvrent la manière d'écrire du HTML pour les exemples de code MDN.

- -

Dans cet article

- - - -

Doctype et méta-données

- -
-

Note : Les directives de cette section ne s'appliquent que lorsque vous devez montrer un document HTML complet. La plupart du temps, vous n'aurez pas besoin de le faire ; un extrait est généralement suffisant pour démontrer une fonctionnalité. Lorsque vous utilisez la macro EmbedLiveSample, il suffit d'inclure l'extrait HTML ; il sera automatiquement inséré dans un document HTML complet lors de son affichage.

-
- -

Doctype

- -

Vous devez utiliser le doctype HTML5. Il est court, facile à retenir et rétrocompatible :

- -
<!DOCTYPE html>
- -

Langue du document

- -

Définissez la langue du document à l'aide de l'attribut lang de votre élément <html> :

- -
<html lang="fr">
- -

C'est bon pour l'accessibilité et les moteurs de recherche, cela aide à localiser le contenu et cela rappelle aux gens d'utiliser les meilleures pratiques.

- -

Jeu de caractères du document

- -

Vous devez également définir le jeu de caractères de votre document comme suit :

- -
<meta charset="utf-8">
- -

Utilisez UTF-8 à moins que vous n'ayez une très bonne raison de ne pas le faire ; il couvrira vos besoins en caractères à peu près indépendamment de la langue que vous utilisez dans votre document. En outre, vous devriez toujours spécifier le jeu de caractères le plus tôt possible dans le bloc <head> de votre HTML (dans le premier kilooctet), car cela vous protège contre une vulnérabilité de sécurité d'Internet Explorer.

- -

Méta-balise Viewport

- -

Enfin, vous devez toujours ajouter la métabalise viewport dans votre HTML <head>, pour donner à l'exemple une meilleure chance de fonctionner sur les appareils mobiles. Vous devez inclure au moins les éléments suivants dans votre document, que vous pourrez modifier ultérieurement en fonction des besoins :

- -
<meta name="viewport" content="width=device-width">
- -

Voir Zones d'affichage sur mobiles pour plus de détails.

- -

Style général de codage des balises

- -

Utiliser les minuscules

- -

Utilisez les minuscules pour tous les noms d'éléments et les noms/valeurs d'attributs, car elles sont plus nettes et vous permettent d'écrire plus rapidement les balises :

- -

C'est bien :

- -
<p class="nice">Ça a l'air sympa et soigné</p>
- -

Ce n'est pas très bon :

- -
<P CLASS="WHOA-THERE">Pourquoi mon balisage crie-t-il ?</P>
- -

Barre oblique de fermeture (slash)

- -

N'incluez pas les barres obliques de fin de style XHTML pour les éléments vides, car elles sont inutiles et ralentissent le processus. Elles peuvent également casser les anciens navigateurs si vous ne faites pas attention (bien que, d'après ce dont nous nous souvenons, cela n'a pas été un problème depuis Netscape 4).

- -

C'est bon :

- -
<input type="text">
-<hr>
- -

Les barres obliques ne sont pas nécessaires :

- -
<input type="text" />
-<hr />
- -

Guillemets des attributs

- -

Vous devez mettre toutes les valeurs d'attribut entre guillemets. Il est tentant d'omettre les guillemets puisque HTML5 le permet, mais le balisage est plus net et plus facile à lire si vous les incluez. Par exemple, ceci est mieux :

- -
<img src="images/logo.jpg" alt="Une icône de globe circulaire" class="no-border">
- -

que ça :

- -
<img src=images/logo.jpg alt=Une icône de globe circulaire class=no-border>
- -

Cela peut également causer des problèmes - dans l'exemple ci-dessus, l'attribut alt sera interprété comme plusieurs attributs, car il n'y a pas de guillemets pour spécifier que "Une icône de globe circulaire" est une valeur d'attribut unique.

- -

Utiliser les guillemets doubles

- -

Utilisez des guillemets doubles pour le HTML, et non des guillemets simples :

- -
<p class="important">Yes</p>
- -
<p class='important'>Nope</p>
- -

Attributs booléens

- -

N'écrivez pas les attributs booléens en entier ; vous pouvez simplement écrire le nom de l'attribut pour le définir. Par exemple, vous pouvez écrire :

- -
required
- -

Ceci est parfaitement compréhensible et fonctionne bien ; la version plus longue avec la valeur est acceptée mais n'est pas nécessaire :

- -
required="required"
- -

Noms de classes et d'ID

- -

Utilisez des noms de classe/ID sémantiques et séparez les mots multiples par des traits d'union. N'utilisez pas de camelCase.

- -

Bon :

- -
<p class="editorial-summary">Blah blah blah</p>
- -

Mauvais :

- -
<p class="bigRedBox">Blah blah blah</p>
- -

Références des entités

- -

N'utilisez pas inutilement les références d'entités - utilisez le caractère littéral chaque fois que cela est possible (vous devrez toujours échapper les caractères comme les crochets et les guillemets).

- -

Par exemple, vous pourriez simplement écrire

- -
<p>© 2018 Me</p>
- -

Au lieu de

- -
<p>&copy; 2018 Me</p>
- -

Cela ne pose aucun problème tant que vous déclarez un jeu de caractères UTF-8.

- -

De bons exemples HTML sur MDN

- -

Vous pouvez trouver de bons extraits HTML, concis et significatifs, en haut des pages de référence HTML - nos exemples interactifs sont généralement rédigés de manière à suivre ces directives, mais sachez qu'ils peuvent différer à certains endroits car ils ont pour la plupart été rédigés avant la nouvelle rédaction des directives.

diff --git a/files/fr/mdn/guidelines/code_guidelines/html/index.md b/files/fr/mdn/guidelines/code_guidelines/html/index.md new file mode 100644 index 0000000000..086c1f5e34 --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/html/index.md @@ -0,0 +1,162 @@ +--- +title: Lignes directrices pour le HTML +slug: MDN/Guidelines/Code_guidelines/HTML +tags: + - Code + - Guide + - Directives + - HTML + - MDN Meta +translation_of: MDN/Guidelines/Code_guidelines/HTML +--- +
{{MDNSidebar}}
+ +

Les directives suivantes couvrent la manière d'écrire du HTML pour les exemples de code MDN.

+ +

Dans cet article

+ + + +

Doctype et méta-données

+ +
+

Note : Les directives de cette section ne s'appliquent que lorsque vous devez montrer un document HTML complet. La plupart du temps, vous n'aurez pas besoin de le faire ; un extrait est généralement suffisant pour démontrer une fonctionnalité. Lorsque vous utilisez la macro EmbedLiveSample, il suffit d'inclure l'extrait HTML ; il sera automatiquement inséré dans un document HTML complet lors de son affichage.

+
+ +

Doctype

+ +

Vous devez utiliser le doctype HTML5. Il est court, facile à retenir et rétrocompatible :

+ +
<!DOCTYPE html>
+ +

Langue du document

+ +

Définissez la langue du document à l'aide de l'attribut lang de votre élément <html> :

+ +
<html lang="fr">
+ +

C'est bon pour l'accessibilité et les moteurs de recherche, cela aide à localiser le contenu et cela rappelle aux gens d'utiliser les meilleures pratiques.

+ +

Jeu de caractères du document

+ +

Vous devez également définir le jeu de caractères de votre document comme suit :

+ +
<meta charset="utf-8">
+ +

Utilisez UTF-8 à moins que vous n'ayez une très bonne raison de ne pas le faire ; il couvrira vos besoins en caractères à peu près indépendamment de la langue que vous utilisez dans votre document. En outre, vous devriez toujours spécifier le jeu de caractères le plus tôt possible dans le bloc <head> de votre HTML (dans le premier kilooctet), car cela vous protège contre une vulnérabilité de sécurité d'Internet Explorer.

+ +

Méta-balise Viewport

+ +

Enfin, vous devez toujours ajouter la métabalise viewport dans votre HTML <head>, pour donner à l'exemple une meilleure chance de fonctionner sur les appareils mobiles. Vous devez inclure au moins les éléments suivants dans votre document, que vous pourrez modifier ultérieurement en fonction des besoins :

+ +
<meta name="viewport" content="width=device-width">
+ +

Voir Zones d'affichage sur mobiles pour plus de détails.

+ +

Style général de codage des balises

+ +

Utiliser les minuscules

+ +

Utilisez les minuscules pour tous les noms d'éléments et les noms/valeurs d'attributs, car elles sont plus nettes et vous permettent d'écrire plus rapidement les balises :

+ +

C'est bien :

+ +
<p class="nice">Ça a l'air sympa et soigné</p>
+ +

Ce n'est pas très bon :

+ +
<P CLASS="WHOA-THERE">Pourquoi mon balisage crie-t-il ?</P>
+ +

Barre oblique de fermeture (slash)

+ +

N'incluez pas les barres obliques de fin de style XHTML pour les éléments vides, car elles sont inutiles et ralentissent le processus. Elles peuvent également casser les anciens navigateurs si vous ne faites pas attention (bien que, d'après ce dont nous nous souvenons, cela n'a pas été un problème depuis Netscape 4).

+ +

C'est bon :

+ +
<input type="text">
+<hr>
+ +

Les barres obliques ne sont pas nécessaires :

+ +
<input type="text" />
+<hr />
+ +

Guillemets des attributs

+ +

Vous devez mettre toutes les valeurs d'attribut entre guillemets. Il est tentant d'omettre les guillemets puisque HTML5 le permet, mais le balisage est plus net et plus facile à lire si vous les incluez. Par exemple, ceci est mieux :

+ +
<img src="images/logo.jpg" alt="Une icône de globe circulaire" class="no-border">
+ +

que ça :

+ +
<img src=images/logo.jpg alt=Une icône de globe circulaire class=no-border>
+ +

Cela peut également causer des problèmes - dans l'exemple ci-dessus, l'attribut alt sera interprété comme plusieurs attributs, car il n'y a pas de guillemets pour spécifier que "Une icône de globe circulaire" est une valeur d'attribut unique.

+ +

Utiliser les guillemets doubles

+ +

Utilisez des guillemets doubles pour le HTML, et non des guillemets simples :

+ +
<p class="important">Yes</p>
+ +
<p class='important'>Nope</p>
+ +

Attributs booléens

+ +

N'écrivez pas les attributs booléens en entier ; vous pouvez simplement écrire le nom de l'attribut pour le définir. Par exemple, vous pouvez écrire :

+ +
required
+ +

Ceci est parfaitement compréhensible et fonctionne bien ; la version plus longue avec la valeur est acceptée mais n'est pas nécessaire :

+ +
required="required"
+ +

Noms de classes et d'ID

+ +

Utilisez des noms de classe/ID sémantiques et séparez les mots multiples par des traits d'union. N'utilisez pas de camelCase.

+ +

Bon :

+ +
<p class="editorial-summary">Blah blah blah</p>
+ +

Mauvais :

+ +
<p class="bigRedBox">Blah blah blah</p>
+ +

Références des entités

+ +

N'utilisez pas inutilement les références d'entités - utilisez le caractère littéral chaque fois que cela est possible (vous devrez toujours échapper les caractères comme les crochets et les guillemets).

+ +

Par exemple, vous pourriez simplement écrire

+ +
<p>© 2018 Me</p>
+ +

Au lieu de

+ +
<p>&copy; 2018 Me</p>
+ +

Cela ne pose aucun problème tant que vous déclarez un jeu de caractères UTF-8.

+ +

De bons exemples HTML sur MDN

+ +

Vous pouvez trouver de bons extraits HTML, concis et significatifs, en haut des pages de référence HTML - nos exemples interactifs sont généralement rédigés de manière à suivre ces directives, mais sachez qu'ils peuvent différer à certains endroits car ils ont pour la plupart été rédigés avant la nouvelle rédaction des directives.

diff --git a/files/fr/mdn/guidelines/code_guidelines/index.html b/files/fr/mdn/guidelines/code_guidelines/index.html deleted file mode 100644 index ab395b6e62..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/index.html +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Lignes directrices pour les fragments de code -slug: MDN/Guidelines/Code_guidelines -tags: - - CSS - - Code - - Guide - - HTML - - JavaScript - - MDN Meta - - Shell -translation_of: MDN/Guidelines/Code_guidelines -original_slug: MDN/Guidelines/Code_lignesdirectrices ---- -
{{MDNSidebar}}
- -

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

-
- -

Structure d'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 :

- - - -

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

- -

Les autres meilleures pratiques générales sont les suivantes :

- - diff --git a/files/fr/mdn/guidelines/code_guidelines/index.md b/files/fr/mdn/guidelines/code_guidelines/index.md new file mode 100644 index 0000000000..ab395b6e62 --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/index.md @@ -0,0 +1,64 @@ +--- +title: Lignes directrices pour les fragments de code +slug: MDN/Guidelines/Code_guidelines +tags: + - CSS + - Code + - Guide + - HTML + - JavaScript + - MDN Meta + - Shell +translation_of: MDN/Guidelines/Code_guidelines +original_slug: MDN/Guidelines/Code_lignesdirectrices +--- +
{{MDNSidebar}}
+ +

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

+
+ +

Structure d'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 :

+ + + +

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

+ +

Les autres meilleures pratiques générales sont les suivantes :

+ + diff --git a/files/fr/mdn/guidelines/code_guidelines/javascript/index.html b/files/fr/mdn/guidelines/code_guidelines/javascript/index.html deleted file mode 100644 index a2178f8491..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/javascript/index.html +++ /dev/null @@ -1,501 +0,0 @@ ---- -title: Lignes directrices pour JavaScript -slug: MDN/Guidelines/Code_guidelines/JavaScript -tags: - - Code - - Guide - - Directives - - JavaScript - - MDN Meta -translation_of: MDN/Guidelines/Code_guidelines/JavaScript ---- -
{{MDNSidebar}}
- -

Les directives suivantes couvrent la manière d'écrire le JavaScript pour les exemples de code MDN.

- -

Ce qui suit est un ensemble assez simple de directives JavaScript. Nous pourrions aller beaucoup plus en profondeur sur ce sujet, mais nous voulons essentiellement fournir des directives simples pour écrire des exemples concis qui seront compréhensibles par le plus grand nombre de personnes possible, plutôt que des directives détaillées pour écrire des applications web complexes. Si vous voulez quelque chose qui entre dans plus de détails, nous vous recommandons le guide stylistique JavaScript d'AirBnB, qui est généralement compatible avec nos directives.

- -

Dans cet article

- - - -

Directives générales sur le JavaScript

- -

Utiliser une syntaxe étendue

- -

Pour JavaScript, nous utilisons une syntaxe étendue, chaque ligne de JS étant placée sur une nouvelle ligne, l'accolade d'ouverture d'un bloc sur la même ligne que l'instruction associée et l'accolade de fermeture sur une nouvelle ligne. Cela permet d'optimiser la lisibilité et de favoriser la cohérence sur le MDN.

- -

Faites ceci

- -
function myFunc() {
-  console.log('Hello!');
-};
- -

Évitez cela

- -
function myFunc() { console.log('Hello!'); };
- -

Nous avons également quelques règles spécifiques concernant l'espacement à l'intérieur des caractéristiques du langage. Vous devez inclure des espaces entre les opérateurs et les opérandes, les paramètres, etc.

- -

C'est plus lisible

- -
if(dayOfWeek === 7 && weather === 'soleil') {
-  goOnTrip('plage', 'voiture', ['crême glacée', 'pelle et sceau', 'serviette de plage']);
-}
- -

que ceci

- -
if(dayOfWeek===7&&weather==='soleil'){
-  goOnTrip('plage','voiture',['crême glacée','pelle et sceau','serviette de plage']);
-}
- -

En outre, gardez ces spécificités à l'esprit :

- - - -

Commentaires JavaScript

- -

Utilisez des commentaires de style JS pour commenter le code qui n'est pas auto-documenté :

- -
// This is a JavaScript-style comment
- -

Mettez vos commentaires sur des lignes séparées précédant le code auquel ils se réfèrent :

- -
function myFunc() {
-  // Affiche la chaîne de caractères "Bonjour" dans la console JS du navigateur.
-  console.log('Bonjour');
-  // Crée un nouveau paragraphe, le remplit de contenu et l'ajoute au <body>
-  let para = document.createElement('p');
-  para.textContent = 'Mon nouveau paragraphe';
-  document.body.appendChild(para);
-}
- -

Notez également que vous devez laisser un espace entre les barres obliques et le commentaire, dans chaque cas.

- -

Utiliser les fonctions ES6

- -

Pour un usage général*, vous pouvez utiliser les fonctionnalités ES6 courantes (telles que les fonctions fléchées, promesses, let/const, littéraux de gabarits, et le syntaxe de décomposition) dans les exemples MDN. Nous les incluons à de nombreux endroits dans ces directives, car nous pensons que l'industrie du Web a généralement atteint un point où ces fonctionnalités sont suffisamment familières pour être compréhensibles. Et pour ceux qui ne les utilisent pas encore, nous aimerions jouer notre rôle en aidant les gens à développer leurs compétences.

- -

Cependant, nous ne recommandons pas encore l'utilisation générale des nouvelles fonctionnalités ES telles que async/await, les virgules de fin sur les listes d'arguments, etc. Nous préférerions que vous ne les utilisiez pas, sauf si cela est strictement nécessaire, et si vous les utilisez, incluez une explication dans votre exemple pour dire ce qu'ils font, avec un lien vers le matériel de référence approprié.

- -
-

Note : Par "usage général", nous entendons la rédaction d'exemples généraux. Les pages de référence couvrant des fonctionnalités spécifiques de l'ES moderne doivent évidemment utiliser les fonctionnalités qu'elles documentent !

-
- -

Variables

- -

Nommage des variables

- -

Pour les noms de variables, utilisez la casse minuscule au format chameau « lowerCamelCase » et, le cas échéant, des noms concis, lisibles par l'homme et sémantiques.

- -

Écrivez comme suit :

- -
let playerScore = 0;
-
-let speed = distance / time;
- -

Éviter ce genre de chose :

- -
let thisIsaveryLONGVariableThatRecordsPlayerscore345654 = 0;
-
-let s = d/t;
-
- -
-

Note : The only place where it is OK to not use human-readable semantic names is where a very common recognized convention exists, such as using i, j, etc. for loop iterators.

-
- -

Déclaration des variables

- -

Lorsque vous déclarez des variables et des constantes, utilisez les mots-clés let et const, pas var.

- -

Si une variable ne sera pas réaffectée, préférez const :

- -
const myName = 'Chris';
-console.log(myName);
-
- -

Sinon, utilisez let :

- -
let myAge = '40';
-myAge++;
-console.log('Happy birthday!');
-
- -

Cet exemple utilise let là où il devrait préférer const. Il fonctionnera mais devrait être évité dans les exemples de code MDN :

- -
let myName = 'Chris';
-console.log(myName);
-
- -

Cet exemple utilise const pour une variable qui est réaffectée. La réaffectation entraînera une erreur :

- -
const myAge = '40';
-myAge++;
-console.log('Happy birthday!');
-
- -

Cet exemple utilise var, ce qui doit être évité dans les exemples de code MDN, sauf si cela est vraiment nécessaire :

- -
var myAge = '40';
-var myName = 'Chris';
- -

Opérateurs et comparaison

- -

Opérateurs ternaires

- -

Les opérateurs ternaires doivent être placés sur une seule ligne :

- -
let status = (age >= 18) ? 'adult' : 'minor';
- -

Pas emboîtés :

- -
let status = (age >= 18)
-  ? 'adult'
-  : 'minor';
- -

C'est beaucoup plus difficile à lire.

- -

Utiliser l'égalité stricte

- -

Utilisez toujours une égalité et une inégalité strictes.

- -

Comme ceci :

- -
name === 'Chris';
-age !== 25;
- -

N'écrivez pas comme ça :

- -
name == 'Chris';
-age != 25;
- -

Utiliser des raccourcis pour les tests booléens

- -

Utilisez des raccourcis pour les tests booléens - utilisez x et !x, et non x === true et x === false.

- -

Instructions de contrôle

- -

Écrivez des instructions de contrôle comme ceci :

- -
if(iceCream) {
-  alert('Woo hoo!');
-}
- -

Pas comme cela :

- -
if (iceCream){
-  alert('Woo hoo!');
-}
- -

N'oubliez pas non plus :

- - - -

Chaînes de caractères

- -

Utiliser des modèles littéraux

- -

Pour insérer des valeurs dans des chaînes de caractères, utilisez des chaînes de caractères littérales.

- -

Comme suit :

- -
let myName = 'Chris';
-console.log(`Hi! I'm ${myName}!`);
- -

En évitant d'écrire :

- -
let myName = 'Chris';
-console.log('Hi! I\'m' + myName + '!');
- -

Utiliser textContent, et non innerHTML

- -

Lorsque vous insérez des chaînes de caractères dans les nœuds du DOM, utilisez la fonction Node.textContent:

- -
let text = 'Bonjour à vous tous, braves gens';
-const para = document.createElement('p');
-para.textContent = text;
- -

Et pas Element.innerHTML:

- -
let text = 'Bonjour à vous tous, braves gens';
-const para = document.createElement('p');
-para.innerHTML = text;
- -

Le textContent est beaucoup plus efficace, et moins sujet aux erreurs que le innerHTML.

- -

Conditions

- -

Usage général des boucles

- -

When loops are required, feel free to choose an appropriate loop out of the available ones (for, for...of, while, etc.) Just make sure to keep the code as understandable as possible.

- -

Lorsque vous utilisez des boucles for/for...of, veillez à définir correctement l'initialisateur, avec un mot clé let :

- -
let cats = ['Athena', 'Luna'];
-for(let i of cats) {
-  console.log(i);
-}
-
- -

Pas

- -
let cats = ['Athena', 'Luna'];
-for(i of cats) {
-  console.log(i);
-}
-
- -

Gardez également à l'esprit :

- - - -

Les instructions switch

- -

Formatez les instructions switch comme suit :

- -
let expr = 'Papayes';
-switch(expr) {
-  case 'Oranges':
-    console.log('Les oranges sont à 1,10 € le kilo.');
-    break;
-  case 'Papayes':
-    console.log('Les mangues et les papayes sont à 5,24 € le kilo.');
-    // résultat attendu : "Les mangues et les papayes sont à 5,24 € le kilo."
-    break;
-  default:
-    console.log('Désolé, nous n'avons plus de ' + expr + '.');
-}
- -

Fonctions et objets

- -

Nommage des fonctions

- -

Pour les noms de fonctions, utilisez la casse minuscule au format chameau « lowevCamelCase » et, le cas échéant, des noms concis, lisibles par l'homme et sémantiques.

- -

Par exemple :

- -
function sayHello() {
-  alert('Bonjour !');
-};
- -

En évitant de faire :

- -
function SayHello() {
-  alert('Bonjour !');
-};
-
-function notVeryObviousName() {
-  alert('Bonjour !');
-};
-
- -
-

Note : Le seul endroit où il est acceptable de ne pas utiliser des noms sémantiques lisibles par l'homme est lorsqu'une convention reconnue très courante existe, comme l'utilisation de i, j, etc. pour les itérateurs de boucle.

-
- -

Définition des fonctions

- -

Dans la mesure du possible, utilisez la déclaration fonction pour définir des fonctions sur des expressions de fonction :

- -

Faites comme ça :

- -
function sum(a, b) {
-  return a + b;
-}
- -

Pas comme ça :

- -
let sum = function(a, b) {
-  return a + b;
-}
- -

Lorsque vous utilisez des fonctions anonymes à l'intérieur d'une méthode qui requiert une fonction comme paramètre, il est acceptable (mais pas obligatoire) d'utiliser une fonction flèche pour rendre le code plus court et plus propre.

- -

Donc, au lieu de ça :

- -
const array1 = [1, 2, 3, 4];
-let sum = array.reduce(function(a, b) {
-  return a + b;
-});
- -

vous pourriez écrire ceci :

- -
const array = [1, 2, 3, 4];
-let sum = array.reduce((a, b) =>
-  a + b
-);
- -

N'oubliez pas non plus :

- - - -

Création d'objets

- -

Utilisez des littéraux - et non des constructeurs - pour créer des objets généraux (c'est-à-dire lorsque les classes ne sont pas concernées) :

- -

Par exemple :

- -
let myObject = { };
- -

Et pas :

- -
let myObject = new Object();
- -

Classes d'objets

- -

Utilisez la syntaxe de classe ES pour les objets, et non les constructeurs à l'ancienne.

- -

À titre d'exemples :

- -
class Person {
-  constructor(name, age, gender) {
-    this.name = name;
-    this.age = age;
-    this.gender = gender;
-  }
-
-  greeting() {
-    console.log(`Salut ! Je m'appelle ${this.name}`);
-  };
-}
- -

Utilisez extends pour l'héritage :

- -
class Teacher extends Person {
-  ...
-}
- -

Nommage des objets

- -

Lorsque vous définissez une classe d'objets (comme ci-dessus), utilisez l'écriture de casse au format chameau en majuscule « UpperCamelCase » (également connue sous le nom de « PascalCasing ») pour le nom de la classe, et la casse en minuscule « lowerCamelCase » pour les noms des propriétés et des méthodes de l'objet.

- -

Lors de la définition d'une instance d'objet, qu'il s'agisse d'un littéral ou d'un constructeur, utilisez le lowerCamelCase pour le nom de l'instance :

- -
let hanSolo = new Person('Han Solo', 25, 'male');
-
-let hanSolo = {
-  name: 'Han Solo',
-  age: 25,
-  gender: 'male'
-}
- -

Tableaux

- -

Création de tableaux

- -

Utilisez des littéraux - et non des constructeurs - pour créer des tableaux :

- -

Comme ceci :

- -
let myArray = [ ];
- -

Pas comme ça :

- -
let myArray = new Array(length);
- -

Ajout à un tableau

- -

Pour ajouter des éléments à un tableau, utilisez push(), et non l'affectation directe. Étant donné le tableau suivant :

- -
const pets = [];
- -

faites ça :

- -
pets.push('cat');
- -

et pas ça :

- -
pets[pets.length] = 'cat';
- -

Traitement des erreurs

- -

Si certains états de votre programme lancent des erreurs non attrapées, ils interrompent l'exécution et réduisent potentiellement l'utilité de l'exemple. Vous devriez donc attraper les erreurs en utilisant un bloc try...catch :

- -
try {
-  console.log(results);
-}
-catch(e) {
-  console.error(e);
-}
- -

De bons exemples de JavaScript sur MDN

- -

Vous pouvez trouver de bons extraits de JavaScript, concis et significatifs, en haut de nos pages Référence du langage JavaScript - parcourez-les pour en trouver.

- -

Nos exemples interactifs (et autres) sont généralement rédigés de manière à suivre les directives ci-dessus, mais sachez qu'ils peuvent différer à certains endroits, car ils ont été rédigés pour la plupart avant que les directives ne soient nouvellement rédigées.

- -

En ce qui concerne les exemples d'API, nous aimerions mettre en avant quelques exemples qui nous semblent bons :

- - diff --git a/files/fr/mdn/guidelines/code_guidelines/javascript/index.md b/files/fr/mdn/guidelines/code_guidelines/javascript/index.md new file mode 100644 index 0000000000..a2178f8491 --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/javascript/index.md @@ -0,0 +1,501 @@ +--- +title: Lignes directrices pour JavaScript +slug: MDN/Guidelines/Code_guidelines/JavaScript +tags: + - Code + - Guide + - Directives + - JavaScript + - MDN Meta +translation_of: MDN/Guidelines/Code_guidelines/JavaScript +--- +
{{MDNSidebar}}
+ +

Les directives suivantes couvrent la manière d'écrire le JavaScript pour les exemples de code MDN.

+ +

Ce qui suit est un ensemble assez simple de directives JavaScript. Nous pourrions aller beaucoup plus en profondeur sur ce sujet, mais nous voulons essentiellement fournir des directives simples pour écrire des exemples concis qui seront compréhensibles par le plus grand nombre de personnes possible, plutôt que des directives détaillées pour écrire des applications web complexes. Si vous voulez quelque chose qui entre dans plus de détails, nous vous recommandons le guide stylistique JavaScript d'AirBnB, qui est généralement compatible avec nos directives.

+ +

Dans cet article

+ + + +

Directives générales sur le JavaScript

+ +

Utiliser une syntaxe étendue

+ +

Pour JavaScript, nous utilisons une syntaxe étendue, chaque ligne de JS étant placée sur une nouvelle ligne, l'accolade d'ouverture d'un bloc sur la même ligne que l'instruction associée et l'accolade de fermeture sur une nouvelle ligne. Cela permet d'optimiser la lisibilité et de favoriser la cohérence sur le MDN.

+ +

Faites ceci

+ +
function myFunc() {
+  console.log('Hello!');
+};
+ +

Évitez cela

+ +
function myFunc() { console.log('Hello!'); };
+ +

Nous avons également quelques règles spécifiques concernant l'espacement à l'intérieur des caractéristiques du langage. Vous devez inclure des espaces entre les opérateurs et les opérandes, les paramètres, etc.

+ +

C'est plus lisible

+ +
if(dayOfWeek === 7 && weather === 'soleil') {
+  goOnTrip('plage', 'voiture', ['crême glacée', 'pelle et sceau', 'serviette de plage']);
+}
+ +

que ceci

+ +
if(dayOfWeek===7&&weather==='soleil'){
+  goOnTrip('plage','voiture',['crême glacée','pelle et sceau','serviette de plage']);
+}
+ +

En outre, gardez ces spécificités à l'esprit :

+ + + +

Commentaires JavaScript

+ +

Utilisez des commentaires de style JS pour commenter le code qui n'est pas auto-documenté :

+ +
// This is a JavaScript-style comment
+ +

Mettez vos commentaires sur des lignes séparées précédant le code auquel ils se réfèrent :

+ +
function myFunc() {
+  // Affiche la chaîne de caractères "Bonjour" dans la console JS du navigateur.
+  console.log('Bonjour');
+  // Crée un nouveau paragraphe, le remplit de contenu et l'ajoute au <body>
+  let para = document.createElement('p');
+  para.textContent = 'Mon nouveau paragraphe';
+  document.body.appendChild(para);
+}
+ +

Notez également que vous devez laisser un espace entre les barres obliques et le commentaire, dans chaque cas.

+ +

Utiliser les fonctions ES6

+ +

Pour un usage général*, vous pouvez utiliser les fonctionnalités ES6 courantes (telles que les fonctions fléchées, promesses, let/const, littéraux de gabarits, et le syntaxe de décomposition) dans les exemples MDN. Nous les incluons à de nombreux endroits dans ces directives, car nous pensons que l'industrie du Web a généralement atteint un point où ces fonctionnalités sont suffisamment familières pour être compréhensibles. Et pour ceux qui ne les utilisent pas encore, nous aimerions jouer notre rôle en aidant les gens à développer leurs compétences.

+ +

Cependant, nous ne recommandons pas encore l'utilisation générale des nouvelles fonctionnalités ES telles que async/await, les virgules de fin sur les listes d'arguments, etc. Nous préférerions que vous ne les utilisiez pas, sauf si cela est strictement nécessaire, et si vous les utilisez, incluez une explication dans votre exemple pour dire ce qu'ils font, avec un lien vers le matériel de référence approprié.

+ +
+

Note : Par "usage général", nous entendons la rédaction d'exemples généraux. Les pages de référence couvrant des fonctionnalités spécifiques de l'ES moderne doivent évidemment utiliser les fonctionnalités qu'elles documentent !

+
+ +

Variables

+ +

Nommage des variables

+ +

Pour les noms de variables, utilisez la casse minuscule au format chameau « lowerCamelCase » et, le cas échéant, des noms concis, lisibles par l'homme et sémantiques.

+ +

Écrivez comme suit :

+ +
let playerScore = 0;
+
+let speed = distance / time;
+ +

Éviter ce genre de chose :

+ +
let thisIsaveryLONGVariableThatRecordsPlayerscore345654 = 0;
+
+let s = d/t;
+
+ +
+

Note : The only place where it is OK to not use human-readable semantic names is where a very common recognized convention exists, such as using i, j, etc. for loop iterators.

+
+ +

Déclaration des variables

+ +

Lorsque vous déclarez des variables et des constantes, utilisez les mots-clés let et const, pas var.

+ +

Si une variable ne sera pas réaffectée, préférez const :

+ +
const myName = 'Chris';
+console.log(myName);
+
+ +

Sinon, utilisez let :

+ +
let myAge = '40';
+myAge++;
+console.log('Happy birthday!');
+
+ +

Cet exemple utilise let là où il devrait préférer const. Il fonctionnera mais devrait être évité dans les exemples de code MDN :

+ +
let myName = 'Chris';
+console.log(myName);
+
+ +

Cet exemple utilise const pour une variable qui est réaffectée. La réaffectation entraînera une erreur :

+ +
const myAge = '40';
+myAge++;
+console.log('Happy birthday!');
+
+ +

Cet exemple utilise var, ce qui doit être évité dans les exemples de code MDN, sauf si cela est vraiment nécessaire :

+ +
var myAge = '40';
+var myName = 'Chris';
+ +

Opérateurs et comparaison

+ +

Opérateurs ternaires

+ +

Les opérateurs ternaires doivent être placés sur une seule ligne :

+ +
let status = (age >= 18) ? 'adult' : 'minor';
+ +

Pas emboîtés :

+ +
let status = (age >= 18)
+  ? 'adult'
+  : 'minor';
+ +

C'est beaucoup plus difficile à lire.

+ +

Utiliser l'égalité stricte

+ +

Utilisez toujours une égalité et une inégalité strictes.

+ +

Comme ceci :

+ +
name === 'Chris';
+age !== 25;
+ +

N'écrivez pas comme ça :

+ +
name == 'Chris';
+age != 25;
+ +

Utiliser des raccourcis pour les tests booléens

+ +

Utilisez des raccourcis pour les tests booléens - utilisez x et !x, et non x === true et x === false.

+ +

Instructions de contrôle

+ +

Écrivez des instructions de contrôle comme ceci :

+ +
if(iceCream) {
+  alert('Woo hoo!');
+}
+ +

Pas comme cela :

+ +
if (iceCream){
+  alert('Woo hoo!');
+}
+ +

N'oubliez pas non plus :

+ + + +

Chaînes de caractères

+ +

Utiliser des modèles littéraux

+ +

Pour insérer des valeurs dans des chaînes de caractères, utilisez des chaînes de caractères littérales.

+ +

Comme suit :

+ +
let myName = 'Chris';
+console.log(`Hi! I'm ${myName}!`);
+ +

En évitant d'écrire :

+ +
let myName = 'Chris';
+console.log('Hi! I\'m' + myName + '!');
+ +

Utiliser textContent, et non innerHTML

+ +

Lorsque vous insérez des chaînes de caractères dans les nœuds du DOM, utilisez la fonction Node.textContent:

+ +
let text = 'Bonjour à vous tous, braves gens';
+const para = document.createElement('p');
+para.textContent = text;
+ +

Et pas Element.innerHTML:

+ +
let text = 'Bonjour à vous tous, braves gens';
+const para = document.createElement('p');
+para.innerHTML = text;
+ +

Le textContent est beaucoup plus efficace, et moins sujet aux erreurs que le innerHTML.

+ +

Conditions

+ +

Usage général des boucles

+ +

When loops are required, feel free to choose an appropriate loop out of the available ones (for, for...of, while, etc.) Just make sure to keep the code as understandable as possible.

+ +

Lorsque vous utilisez des boucles for/for...of, veillez à définir correctement l'initialisateur, avec un mot clé let :

+ +
let cats = ['Athena', 'Luna'];
+for(let i of cats) {
+  console.log(i);
+}
+
+ +

Pas

+ +
let cats = ['Athena', 'Luna'];
+for(i of cats) {
+  console.log(i);
+}
+
+ +

Gardez également à l'esprit :

+ + + +

Les instructions switch

+ +

Formatez les instructions switch comme suit :

+ +
let expr = 'Papayes';
+switch(expr) {
+  case 'Oranges':
+    console.log('Les oranges sont à 1,10 € le kilo.');
+    break;
+  case 'Papayes':
+    console.log('Les mangues et les papayes sont à 5,24 € le kilo.');
+    // résultat attendu : "Les mangues et les papayes sont à 5,24 € le kilo."
+    break;
+  default:
+    console.log('Désolé, nous n'avons plus de ' + expr + '.');
+}
+ +

Fonctions et objets

+ +

Nommage des fonctions

+ +

Pour les noms de fonctions, utilisez la casse minuscule au format chameau « lowevCamelCase » et, le cas échéant, des noms concis, lisibles par l'homme et sémantiques.

+ +

Par exemple :

+ +
function sayHello() {
+  alert('Bonjour !');
+};
+ +

En évitant de faire :

+ +
function SayHello() {
+  alert('Bonjour !');
+};
+
+function notVeryObviousName() {
+  alert('Bonjour !');
+};
+
+ +
+

Note : Le seul endroit où il est acceptable de ne pas utiliser des noms sémantiques lisibles par l'homme est lorsqu'une convention reconnue très courante existe, comme l'utilisation de i, j, etc. pour les itérateurs de boucle.

+
+ +

Définition des fonctions

+ +

Dans la mesure du possible, utilisez la déclaration fonction pour définir des fonctions sur des expressions de fonction :

+ +

Faites comme ça :

+ +
function sum(a, b) {
+  return a + b;
+}
+ +

Pas comme ça :

+ +
let sum = function(a, b) {
+  return a + b;
+}
+ +

Lorsque vous utilisez des fonctions anonymes à l'intérieur d'une méthode qui requiert une fonction comme paramètre, il est acceptable (mais pas obligatoire) d'utiliser une fonction flèche pour rendre le code plus court et plus propre.

+ +

Donc, au lieu de ça :

+ +
const array1 = [1, 2, 3, 4];
+let sum = array.reduce(function(a, b) {
+  return a + b;
+});
+ +

vous pourriez écrire ceci :

+ +
const array = [1, 2, 3, 4];
+let sum = array.reduce((a, b) =>
+  a + b
+);
+ +

N'oubliez pas non plus :

+ + + +

Création d'objets

+ +

Utilisez des littéraux - et non des constructeurs - pour créer des objets généraux (c'est-à-dire lorsque les classes ne sont pas concernées) :

+ +

Par exemple :

+ +
let myObject = { };
+ +

Et pas :

+ +
let myObject = new Object();
+ +

Classes d'objets

+ +

Utilisez la syntaxe de classe ES pour les objets, et non les constructeurs à l'ancienne.

+ +

À titre d'exemples :

+ +
class Person {
+  constructor(name, age, gender) {
+    this.name = name;
+    this.age = age;
+    this.gender = gender;
+  }
+
+  greeting() {
+    console.log(`Salut ! Je m'appelle ${this.name}`);
+  };
+}
+ +

Utilisez extends pour l'héritage :

+ +
class Teacher extends Person {
+  ...
+}
+ +

Nommage des objets

+ +

Lorsque vous définissez une classe d'objets (comme ci-dessus), utilisez l'écriture de casse au format chameau en majuscule « UpperCamelCase » (également connue sous le nom de « PascalCasing ») pour le nom de la classe, et la casse en minuscule « lowerCamelCase » pour les noms des propriétés et des méthodes de l'objet.

+ +

Lors de la définition d'une instance d'objet, qu'il s'agisse d'un littéral ou d'un constructeur, utilisez le lowerCamelCase pour le nom de l'instance :

+ +
let hanSolo = new Person('Han Solo', 25, 'male');
+
+let hanSolo = {
+  name: 'Han Solo',
+  age: 25,
+  gender: 'male'
+}
+ +

Tableaux

+ +

Création de tableaux

+ +

Utilisez des littéraux - et non des constructeurs - pour créer des tableaux :

+ +

Comme ceci :

+ +
let myArray = [ ];
+ +

Pas comme ça :

+ +
let myArray = new Array(length);
+ +

Ajout à un tableau

+ +

Pour ajouter des éléments à un tableau, utilisez push(), et non l'affectation directe. Étant donné le tableau suivant :

+ +
const pets = [];
+ +

faites ça :

+ +
pets.push('cat');
+ +

et pas ça :

+ +
pets[pets.length] = 'cat';
+ +

Traitement des erreurs

+ +

Si certains états de votre programme lancent des erreurs non attrapées, ils interrompent l'exécution et réduisent potentiellement l'utilité de l'exemple. Vous devriez donc attraper les erreurs en utilisant un bloc try...catch :

+ +
try {
+  console.log(results);
+}
+catch(e) {
+  console.error(e);
+}
+ +

De bons exemples de JavaScript sur MDN

+ +

Vous pouvez trouver de bons extraits de JavaScript, concis et significatifs, en haut de nos pages Référence du langage JavaScript - parcourez-les pour en trouver.

+ +

Nos exemples interactifs (et autres) sont généralement rédigés de manière à suivre les directives ci-dessus, mais sachez qu'ils peuvent différer à certains endroits, car ils ont été rédigés pour la plupart avant que les directives ne soient nouvellement rédigées.

+ +

En ce qui concerne les exemples d'API, nous aimerions mettre en avant quelques exemples qui nous semblent bons :

+ + diff --git a/files/fr/mdn/guidelines/code_guidelines/shell/index.html b/files/fr/mdn/guidelines/code_guidelines/shell/index.html deleted file mode 100644 index a3a1cba4b0..0000000000 --- a/files/fr/mdn/guidelines/code_guidelines/shell/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Lignes directrices des exemples de lignes de commande -slug: MDN/Guidelines/Code_guidelines/Shell -tags: - - Code - - Guide - - Guidelines - - MDN Meta - - Shell -translation_of: MDN/Guidelines/Code_guidelines/Shell ---- -
{{MDNSidebar}}
- -

Les directives suivantes expliquent comment rédiger des exemples de lignes de commande sur MDN.

- -

Les commandes Shell en bref

- -

Un shell est un programme qui attend que vous tapiez une commande et que vous appuyiez sur la touche retour. Pour indiquer les commandes que vous devez taper, la documentation MDN les répertorie dans un bloc de code, similaire aux exemples de code. Un tel bloc ressemble à ceci :

- -
# Cela peut prendre un certain temps…
-hg clone https://hg.mozilla.org/mozilla-central/ firefox
-cd firefox
- -

Directives

- -

Il existe quelques directives à suivre lors de l'écriture d'un bloc de code shell :

- - - -

De bons exemples de commandes shell sur le MDN

- -

Nos Documents de développement côté serveur de Django montrent une bonne pratique de présentation des commandes de l'invite shell, etc. sur le MDN. Regardez Configurer un environnement de développement Django par exemple.

- diff --git a/files/fr/mdn/guidelines/code_guidelines/shell/index.md b/files/fr/mdn/guidelines/code_guidelines/shell/index.md new file mode 100644 index 0000000000..a3a1cba4b0 --- /dev/null +++ b/files/fr/mdn/guidelines/code_guidelines/shell/index.md @@ -0,0 +1,37 @@ +--- +title: Lignes directrices des exemples de lignes de commande +slug: MDN/Guidelines/Code_guidelines/Shell +tags: + - Code + - Guide + - Guidelines + - MDN Meta + - Shell +translation_of: MDN/Guidelines/Code_guidelines/Shell +--- +
{{MDNSidebar}}
+ +

Les directives suivantes expliquent comment rédiger des exemples de lignes de commande sur MDN.

+ +

Les commandes Shell en bref

+ +

Un shell est un programme qui attend que vous tapiez une commande et que vous appuyiez sur la touche retour. Pour indiquer les commandes que vous devez taper, la documentation MDN les répertorie dans un bloc de code, similaire aux exemples de code. Un tel bloc ressemble à ceci :

+ +
# Cela peut prendre un certain temps…
+hg clone https://hg.mozilla.org/mozilla-central/ firefox
+cd firefox
+ +

Directives

+ +

Il existe quelques directives à suivre lors de l'écriture d'un bloc de code shell :

+ + + +

De bons exemples de commandes shell sur le MDN

+ +

Nos Documents de développement côté serveur de Django montrent une bonne pratique de présentation des commandes de l'invite shell, etc. sur le MDN. Regardez Configurer un environnement de développement Django par exemple.

+ diff --git a/files/fr/mdn/guidelines/conventions_definitions/index.html b/files/fr/mdn/guidelines/conventions_definitions/index.html deleted file mode 100644 index 72ac92bc7c..0000000000 --- a/files/fr/mdn/guidelines/conventions_definitions/index.html +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Conventions et définitions relatives à MDN -slug: MDN/Guidelines/Conventions_definitions -tags: - - Documentation - - Guide - - Guidelines - - MDN - - MDN Meta -translation_of: MDN/Guidelines/Conventions_definitions ---- -
{{MDNSidebar}}
- -

Cet article définit certaines conventions et définitions couramment utilisées sur MDN et qui pourraient ne pas être évidentes au sein de la documentation.

- -

Définitions

- -

Déprécié et obsolète

- -

Les adjectifs déprécié et obsolète sont souvent associés à des technologies ou à des spécifications : qu'est-ce que cela signifie ?

- -
-
Déprécié (deprecated en anglais)
-
Sur MDN, le terme déprécié est utilisé afin d'indiquer qu'une API ou une technologie n'est plus recommandée bien qu'elle soit toujours implémentée et qu'elle puisse encore fonctionner. Nous avons mis à jour la définition utilisée pour le projet browser-compat-data qui indique "cette fonctionnalité n'est désormais plus recommandée. Elle pourra être supprimée à l'avenir ou être conservée uniquement à des fins de compatibilité. Veuillez éviter d'utiliser cette fonctionnalité."
-
Obsolète
-
Sur MDN, le terme obsolète est utilisé afin d'indiquer une API ou une technologie qui n'est plus recommandée et qui n'est plus implémentée dans les navigateurs. Cette nuance avec la dépréciation pouvait être source de confusion et peu utile (dans les deux cas, on doit éviter d'utiliser une telle fonctionnalité pour un site ou une application en production). Nous n'utilisons plus cette notion désormais et toute occurrence devrait être retirée/remplacée par « déprécié ».
-
- -

Expérimental

- -

Expérimental peut avoir différentes significations en fonction du contexte. Lorsqu'on décrit une technologie comme expérimentale sur MDN, cela signifie qu'elle est en cours de conception/implémentation et en train d'être ajoutée à la plateforme web (ou que son ajout est envisagé).

- -

Au moins un des deux points qui suivent sera vérifié :

- - - -

Si l'une ou l'autre (ou les deux) de ces propositions est vraie, il est préférable de réfléchir avant d'ajouter cette technologique à un projet de production (qui n'est ni une démonstration ni une expérimentation). Voir aussi la définition d'« expérimental » dans le projet browser-compat-data.

- -

À l'inverse, quelque chose n'est plus expérimental lorsque :

- - - -

Le ou a toute son importance ici. Généralement, si une technologie est implémentée sur différents navigateurs principaux, la spécification sera stable. Toutefois, ce n'est pas toujours le cas. On a aussi des technologies dont la spécification est stable mais qui ne sont pas implémentées nativement dans les navigateurs (voir IMSC, par exemple).

- -

Pages archivées

- -

Les pages archivées sont des pages stockées dans les archives MDN pour le contenu obsolète. Ces pages contiennent des informations caduques qui ne sont plus directement utiles.

- -

Pour la plupart, elles concernent des projets Mozilla qui ont été arrêtés et qu'on ne devrait plus utiliser. Elles ne sont cependant pas supprimées en raison de leur valeur historique et de certains concepts ou idées qui pourraient s'avérer utiles pour de futurs projets (un bon exemple est le projet B2G (Firefox OS)).

- -

Comment décider de l'archivage d'une page ?

- -

Une page devrait être archivée si elle s'inscrit dans la description précédente. Pour archiver une page, voir la documentation correspondante sur GitHub.

- -

Pages supprimées

- -

Les pages supprimées ont été explicitement supprimées de MDN. On aura par exemple l'interface SharedKeyframeList et le constructeur SharedKeyframeList(). Ces pages contenaient des informations qui ne sont plus utiles à qui que ce soit et/ou qui sont incorrectes au point qu'elles peuvent être source de confusion ou d'interprétations erronées.

- -

Il peut s'agir :

- - - -

Comment décider de la suppression d'une page ?

- -

Une page devrait être supprimée si elle correspond à la description précédente. Pour supprimer une page, voir la documentation sur GitHub.

- -

Quand documenter de nouvelles technologies

- -

Sur MDN, nous cherchons continuellement à documenter les technologies web standard comme il se doit. Il faut donc trouver un équilibre entre une documentation publiée suffisamment tôt afin que les développeurs puissent découvrir les nouvelles fonctionnalités lorsqu'ils en ont besoin et une documentation publiée suffisamment tard afin que la technologie en question soit suffisamment mature et stable afin que la documentation n'ait pas à être réécrite constamment ou à être supprimée rapidement suite à des changements de rupture dans les spécifications.

- -

En général, le seuil pour déclencher la documentation d'une nouvelle technologie web correspond au moment où :

- -

« La fonctionnalité est en voie de standardisation et implémentée quelque part. »

- -

Une nouvelle technologie mérite sans doute d'être documentée si :

- - - -

Il faut prendre ses précautions quant à la documentation d'une nouvelle technologie si :

- - - -

Une nouvelle technologie ne doit pas être documentée si :

- - - -

Conventions

- -

Lors du retrait d'une fonctionnalité de la spécification

- -

Il arrive parfois, pendant le développement d'une spécification et au fur à et mesure de l'évolution de standards évolutifs que de nouveaux éléments, de nouvelles méthodes ou propriétés ou autres soient ajoutés à la spécification, y restent pendant quelque temps avant d'être retirés. Cela arrive parfois rapidement et peut aussi prendre plusieurs mois ou années avant que la suppression soit effectuée. Gérer cette suppression dans la documentation peut alors s'avérer délicat. Voici quelques lignes directrices pour vous aider à décider de ce qu'il faut faire.

- -
-

Note : Pour la suite de cette discussion, le terme « élément » sera utilisé de façon générique pour indique n'importe quel objet qui peut faire partie d'une spécification : un élément, un attribut d'un élément, une interface, une méthode spécifique, une propriété, un membre d'une interface, etc.

-
- - - -

Les formulations exactes des avertissements et autres messages doivent être adaptées si besoin. En cas de doute sur la formulation, n'hésitez pas à vous rendre sur le canal MDN sur Matrix ou sur le forum de discussion Discourse.

- -

Copier du contenu d'une source tierce sur MDN

- -

Il existe souvent du contenu utile sur un sujet donné en dehors de MDN. Toutefois, copier ce contenu peut s'accompagner de pénalités légales ou techniques.

- -

Sur le plan technique, les moteurs de recherche ont tendance à pénaliser le classement d'un site qui reproduit du contenu existant par ailleurs. Il est donc préférable d'avoir du contenu original sur MDN pour veiller au bon référencement. On peut tout à fait ajouter des liens vers du contenu externe.

- -

Sur le plan légal, il faut être autorisé à contribuer au contenu et il doit être sous une licence et une attribution compatible avec celle de MDN.

- - - -

Comment indiquer un conflit de spécification

- -

Il arrive (rarement) qu'il y ait un conflit entre les différentes versions d'une spécification (généralement pour celles du W3C et du WHATWG). Par exemple, une des spécifications peut indiquer une fonctionnalité comme dépréciée tandis que l'autre n'indique pas cet état. Dans ces cas, on étudiera le comportement réel des navigateurs et on écrira une note afin d'indiquer cet état. Ainsi, en janvier 2019, l'attribut global inputmode était touché par un conflit de spécification qui était indiqué ainsi sur la page :

- -
-

Attention : Conflit de spécification : La spécification WHATWG liste l'attribut inputmode et les navigateurs travaillent à son implémentation. La spécification W3C HTML 5.2 ne le mentionne plus en revanche (ce qui indique qu'il est considéré comme obsolète). Jusqu'à ce qu'un consensus soit atteint, on pourra considérer que c'est la définition du WHATWG qui est correcte.

-
diff --git a/files/fr/mdn/guidelines/conventions_definitions/index.md b/files/fr/mdn/guidelines/conventions_definitions/index.md new file mode 100644 index 0000000000..72ac92bc7c --- /dev/null +++ b/files/fr/mdn/guidelines/conventions_definitions/index.md @@ -0,0 +1,175 @@ +--- +title: Conventions et définitions relatives à MDN +slug: MDN/Guidelines/Conventions_definitions +tags: + - Documentation + - Guide + - Guidelines + - MDN + - MDN Meta +translation_of: MDN/Guidelines/Conventions_definitions +--- +
{{MDNSidebar}}
+ +

Cet article définit certaines conventions et définitions couramment utilisées sur MDN et qui pourraient ne pas être évidentes au sein de la documentation.

+ +

Définitions

+ +

Déprécié et obsolète

+ +

Les adjectifs déprécié et obsolète sont souvent associés à des technologies ou à des spécifications : qu'est-ce que cela signifie ?

+ +
+
Déprécié (deprecated en anglais)
+
Sur MDN, le terme déprécié est utilisé afin d'indiquer qu'une API ou une technologie n'est plus recommandée bien qu'elle soit toujours implémentée et qu'elle puisse encore fonctionner. Nous avons mis à jour la définition utilisée pour le projet browser-compat-data qui indique "cette fonctionnalité n'est désormais plus recommandée. Elle pourra être supprimée à l'avenir ou être conservée uniquement à des fins de compatibilité. Veuillez éviter d'utiliser cette fonctionnalité."
+
Obsolète
+
Sur MDN, le terme obsolète est utilisé afin d'indiquer une API ou une technologie qui n'est plus recommandée et qui n'est plus implémentée dans les navigateurs. Cette nuance avec la dépréciation pouvait être source de confusion et peu utile (dans les deux cas, on doit éviter d'utiliser une telle fonctionnalité pour un site ou une application en production). Nous n'utilisons plus cette notion désormais et toute occurrence devrait être retirée/remplacée par « déprécié ».
+
+ +

Expérimental

+ +

Expérimental peut avoir différentes significations en fonction du contexte. Lorsqu'on décrit une technologie comme expérimentale sur MDN, cela signifie qu'elle est en cours de conception/implémentation et en train d'être ajoutée à la plateforme web (ou que son ajout est envisagé).

+ +

Au moins un des deux points qui suivent sera vérifié :

+ + + +

Si l'une ou l'autre (ou les deux) de ces propositions est vraie, il est préférable de réfléchir avant d'ajouter cette technologique à un projet de production (qui n'est ni une démonstration ni une expérimentation). Voir aussi la définition d'« expérimental » dans le projet browser-compat-data.

+ +

À l'inverse, quelque chose n'est plus expérimental lorsque :

+ + + +

Le ou a toute son importance ici. Généralement, si une technologie est implémentée sur différents navigateurs principaux, la spécification sera stable. Toutefois, ce n'est pas toujours le cas. On a aussi des technologies dont la spécification est stable mais qui ne sont pas implémentées nativement dans les navigateurs (voir IMSC, par exemple).

+ +

Pages archivées

+ +

Les pages archivées sont des pages stockées dans les archives MDN pour le contenu obsolète. Ces pages contiennent des informations caduques qui ne sont plus directement utiles.

+ +

Pour la plupart, elles concernent des projets Mozilla qui ont été arrêtés et qu'on ne devrait plus utiliser. Elles ne sont cependant pas supprimées en raison de leur valeur historique et de certains concepts ou idées qui pourraient s'avérer utiles pour de futurs projets (un bon exemple est le projet B2G (Firefox OS)).

+ +

Comment décider de l'archivage d'une page ?

+ +

Une page devrait être archivée si elle s'inscrit dans la description précédente. Pour archiver une page, voir la documentation correspondante sur GitHub.

+ +

Pages supprimées

+ +

Les pages supprimées ont été explicitement supprimées de MDN. On aura par exemple l'interface SharedKeyframeList et le constructeur SharedKeyframeList(). Ces pages contenaient des informations qui ne sont plus utiles à qui que ce soit et/ou qui sont incorrectes au point qu'elles peuvent être source de confusion ou d'interprétations erronées.

+ +

Il peut s'agir :

+ + + +

Comment décider de la suppression d'une page ?

+ +

Une page devrait être supprimée si elle correspond à la description précédente. Pour supprimer une page, voir la documentation sur GitHub.

+ +

Quand documenter de nouvelles technologies

+ +

Sur MDN, nous cherchons continuellement à documenter les technologies web standard comme il se doit. Il faut donc trouver un équilibre entre une documentation publiée suffisamment tôt afin que les développeurs puissent découvrir les nouvelles fonctionnalités lorsqu'ils en ont besoin et une documentation publiée suffisamment tard afin que la technologie en question soit suffisamment mature et stable afin que la documentation n'ait pas à être réécrite constamment ou à être supprimée rapidement suite à des changements de rupture dans les spécifications.

+ +

En général, le seuil pour déclencher la documentation d'une nouvelle technologie web correspond au moment où :

+ +

« La fonctionnalité est en voie de standardisation et implémentée quelque part. »

+ +

Une nouvelle technologie mérite sans doute d'être documentée si :

+ + + +

Il faut prendre ses précautions quant à la documentation d'une nouvelle technologie si :

+ + + +

Une nouvelle technologie ne doit pas être documentée si :

+ + + +

Conventions

+ +

Lors du retrait d'une fonctionnalité de la spécification

+ +

Il arrive parfois, pendant le développement d'une spécification et au fur à et mesure de l'évolution de standards évolutifs que de nouveaux éléments, de nouvelles méthodes ou propriétés ou autres soient ajoutés à la spécification, y restent pendant quelque temps avant d'être retirés. Cela arrive parfois rapidement et peut aussi prendre plusieurs mois ou années avant que la suppression soit effectuée. Gérer cette suppression dans la documentation peut alors s'avérer délicat. Voici quelques lignes directrices pour vous aider à décider de ce qu'il faut faire.

+ +
+

Note : Pour la suite de cette discussion, le terme « élément » sera utilisé de façon générique pour indique n'importe quel objet qui peut faire partie d'une spécification : un élément, un attribut d'un élément, une interface, une méthode spécifique, une propriété, un membre d'une interface, etc.

+
+ + + +

Les formulations exactes des avertissements et autres messages doivent être adaptées si besoin. En cas de doute sur la formulation, n'hésitez pas à vous rendre sur le canal MDN sur Matrix ou sur le forum de discussion Discourse.

+ +

Copier du contenu d'une source tierce sur MDN

+ +

Il existe souvent du contenu utile sur un sujet donné en dehors de MDN. Toutefois, copier ce contenu peut s'accompagner de pénalités légales ou techniques.

+ +

Sur le plan technique, les moteurs de recherche ont tendance à pénaliser le classement d'un site qui reproduit du contenu existant par ailleurs. Il est donc préférable d'avoir du contenu original sur MDN pour veiller au bon référencement. On peut tout à fait ajouter des liens vers du contenu externe.

+ +

Sur le plan légal, il faut être autorisé à contribuer au contenu et il doit être sous une licence et une attribution compatible avec celle de MDN.

+ + + +

Comment indiquer un conflit de spécification

+ +

Il arrive (rarement) qu'il y ait un conflit entre les différentes versions d'une spécification (généralement pour celles du W3C et du WHATWG). Par exemple, une des spécifications peut indiquer une fonctionnalité comme dépréciée tandis que l'autre n'indique pas cet état. Dans ces cas, on étudiera le comportement réel des navigateurs et on écrira une note afin d'indiquer cet état. Ainsi, en janvier 2019, l'attribut global inputmode était touché par un conflit de spécification qui était indiqué ainsi sur la page :

+ +
+

Attention : Conflit de spécification : La spécification WHATWG liste l'attribut inputmode et les navigateurs travaillent à son implémentation. La spécification W3C HTML 5.2 ne le mentionne plus en revanche (ce qui indique qu'il est considéré comme obsolète). Jusqu'à ce qu'un consensus soit atteint, on pourra considérer que c'est la définition du WHATWG qui est correcte.

+
diff --git a/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.html b/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.html deleted file mode 100644 index a2355886d6..0000000000 --- a/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Ceci a-t-il sa place sur MDN ? -slug: MDN/Guidelines/Does_this_belong_on_MDN -tags: - - Guide - - Guidelines - - MDN Meta -translation_of: MDN/Guidelines/Does_this_belong_on_MDN ---- -
{{MDNSidebar}}
- -

Dans cet article, nous verrons comment décider de si un sujet ou un type de contenu doit être documenté sur MDN. Nous verrons également les autres emplacements où ce contenu pourra résider.

- -

La question

- -

Si vous préparez la documentation d'un sujet, vous vous demandez peut-être si sa place est sur MDN. Vous envisagez peut-être de maintenir la documentation dans votre code source ou de publier sur le wiki de Mozilla ou dans les fichiers README d'un dépôt Git. Voyons quelles sont les meilleures options pour votre contenu.

- -

Les deux aspects principaux qui permettent de déterminer si un contenu a sa place sur MDN sont :

- - - -

Attention, toute contribution à MDN s'inscrit avec des licences open source. Celles-ci sont décrites en détail dans notre page À propos de MDN.

- -
-

Note : Les Conditions d'utilisation des sites web et de communication de Mozilla s'appliquent lorsque vous contribuez à MDN. Lisez ce document pour connaître ce qui peut et ce qui ne peut pas être publié sur les sites de Mozilla.

-
- -

Ce qui a sa place sur MDN

- -

En général, MDN est utilisé pour documenter les technologies web open source. Cela comprend toute fonctionnalité qui peut être utilisée par les développeuses et développeurs web afin de créer des sites et des applications web. S'il s'agit d'une fonctionnalité implémentée par plusieurs navigateurs et spécifiée de façon standard ou en voie de standardisation, alors sa documentation a pleinement sa place sur MDN. S'il s'agit d'une fonctionnalité expérimentale et qui n'est pas implémentée dans plusieurs navigateurs ou qui est sujette à modification alors elle pourra être documentée mais ne sera pas forcément priorisée.

- -

Les sujets majeurs de MDN sont les technologies web côté client :

- - - -
-

Note : Les technologies côté serveur sont généralement documentées autre part et cette documentation n'est pas remplacée par MDN, mais il existe quelques exceptions.

-
- -

Les sujets relatifs au développement web et qui portent sur différentes technologies sont également les bienvenus sur MDN :

- - - -
-

Note : MDN documente certaines fonctionnalités non-standard lorsqu'elles sont exposées sur le Web et que leur usage est important (comme les propriétés CSS spécifiques à WebKit par exemple). MDN documente également certaines technologies standard, hors du Web, si celles-ci s'avèrent utiles aux développeuses et développeurs web : voir la section sur les technologies connexes au Web.

-
- -

Ce qui n'a pas sa place sur MDN

- -

De façon générale, tout ce qui n'est pas décrit par un standard ouvert du Web n'appartient pas à MDN. Cette section indique quelques règles complémentaires.

- -

Produits Mozilla

- -

Le contenu de MDN portait auparavant également sur les produits de Mozilla. Cette documentation a été migrée vers d'autres projets :

- - - -

Quoi d'autre ?

- -

Voici d'autres exemples de sujets inappropriés pour MDN :

- - \ No newline at end of file diff --git a/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.md b/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.md new file mode 100644 index 0000000000..a2355886d6 --- /dev/null +++ b/files/fr/mdn/guidelines/does_this_belong_on_mdn/index.md @@ -0,0 +1,87 @@ +--- +title: Ceci a-t-il sa place sur MDN ? +slug: MDN/Guidelines/Does_this_belong_on_MDN +tags: + - Guide + - Guidelines + - MDN Meta +translation_of: MDN/Guidelines/Does_this_belong_on_MDN +--- +
{{MDNSidebar}}
+ +

Dans cet article, nous verrons comment décider de si un sujet ou un type de contenu doit être documenté sur MDN. Nous verrons également les autres emplacements où ce contenu pourra résider.

+ +

La question

+ +

Si vous préparez la documentation d'un sujet, vous vous demandez peut-être si sa place est sur MDN. Vous envisagez peut-être de maintenir la documentation dans votre code source ou de publier sur le wiki de Mozilla ou dans les fichiers README d'un dépôt Git. Voyons quelles sont les meilleures options pour votre contenu.

+ +

Les deux aspects principaux qui permettent de déterminer si un contenu a sa place sur MDN sont :

+ + + +

Attention, toute contribution à MDN s'inscrit avec des licences open source. Celles-ci sont décrites en détail dans notre page À propos de MDN.

+ +
+

Note : Les Conditions d'utilisation des sites web et de communication de Mozilla s'appliquent lorsque vous contribuez à MDN. Lisez ce document pour connaître ce qui peut et ce qui ne peut pas être publié sur les sites de Mozilla.

+
+ +

Ce qui a sa place sur MDN

+ +

En général, MDN est utilisé pour documenter les technologies web open source. Cela comprend toute fonctionnalité qui peut être utilisée par les développeuses et développeurs web afin de créer des sites et des applications web. S'il s'agit d'une fonctionnalité implémentée par plusieurs navigateurs et spécifiée de façon standard ou en voie de standardisation, alors sa documentation a pleinement sa place sur MDN. S'il s'agit d'une fonctionnalité expérimentale et qui n'est pas implémentée dans plusieurs navigateurs ou qui est sujette à modification alors elle pourra être documentée mais ne sera pas forcément priorisée.

+ +

Les sujets majeurs de MDN sont les technologies web côté client :

+ + + +
+

Note : Les technologies côté serveur sont généralement documentées autre part et cette documentation n'est pas remplacée par MDN, mais il existe quelques exceptions.

+
+ +

Les sujets relatifs au développement web et qui portent sur différentes technologies sont également les bienvenus sur MDN :

+ + + +
+

Note : MDN documente certaines fonctionnalités non-standard lorsqu'elles sont exposées sur le Web et que leur usage est important (comme les propriétés CSS spécifiques à WebKit par exemple). MDN documente également certaines technologies standard, hors du Web, si celles-ci s'avèrent utiles aux développeuses et développeurs web : voir la section sur les technologies connexes au Web.

+
+ +

Ce qui n'a pas sa place sur MDN

+ +

De façon générale, tout ce qui n'est pas décrit par un standard ouvert du Web n'appartient pas à MDN. Cette section indique quelques règles complémentaires.

+ +

Produits Mozilla

+ +

Le contenu de MDN portait auparavant également sur les produits de Mozilla. Cette documentation a été migrée vers d'autres projets :

+ + + +

Quoi d'autre ?

+ +

Voici d'autres exemples de sujets inappropriés pour MDN :

+ + \ No newline at end of file diff --git a/files/fr/mdn/guidelines/editorial/index.html b/files/fr/mdn/guidelines/editorial/index.html deleted file mode 100644 index ffd2cc922c..0000000000 --- a/files/fr/mdn/guidelines/editorial/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Règles éditoriales -slug: MDN/Guidelines/Editorial -tags: - - Documentation - - MDN - - MDN Meta - - Writing -translation_of: MDN/Guidelines/Editorial ---- -
{{MDNSidebar}}
- -

Cet article décrit les règles définies par l'équipe MDN pour le contenu de MDN. Toute personne qui contribue à MDN se doit de respecter ces règles.

- -

Pertinence

- -

Le contenu de MDN doit être pertinent par rapport à la section dans laquelle il apparaît. Le spam et les publicités ou tout autre contenu inapproprié ne sera jamais accepté. Les personnes qui éditent afin d'ajouter ce type de contenu pourront être bannies sans avertissement.

- -

Les liens sortants vers des sites commerciaux mais qui sont pertinents pour le sujet seront examinés au cas par cas. Leur valeur ajoutée à destination des développeuses et développeurs web doit dépasser le bénéfice commercial que tirera le site cible.

- -

Neutralité

- -

Le contenu d'un article de MDN doit conserver un point de vue neutre et les différences entre les navigateurs doivent être documentées sans biais. Les commentaires subjectifs et péjoratifs à propos d'un navigateur ou d'un agent utilisateur en particulier ne sont pas acceptables.

- -

Web ouvert

- -

MDN contient des documentations agnostiques aux différents navigateurs afin de permettre aux développeuses et développeurs web d'écrire du code qui fonctionne dans les différents navigateurs.

- -

Les technologies documentées sur MDN doivent a minima être en voie de standardisation et être implémentée par au moins un navigateur. Les différences de compatibilité sont documentées dans les tableaux de compatibilité des articles.

- -

Structure

- -

Les pages de référence doivent suivre la même structure que les autres pages du même type. Voir les types de page pour une liste d'exemple des structures communément utilisées sur MDN.

- -

Règles générales

- -

Les contributrices et contributeurs doivent suivre les lignes directrices de MDN quant au style d'écriture, aux exemples de code, etc.

diff --git a/files/fr/mdn/guidelines/editorial/index.md b/files/fr/mdn/guidelines/editorial/index.md new file mode 100644 index 0000000000..ffd2cc922c --- /dev/null +++ b/files/fr/mdn/guidelines/editorial/index.md @@ -0,0 +1,37 @@ +--- +title: Règles éditoriales +slug: MDN/Guidelines/Editorial +tags: + - Documentation + - MDN + - MDN Meta + - Writing +translation_of: MDN/Guidelines/Editorial +--- +
{{MDNSidebar}}
+ +

Cet article décrit les règles définies par l'équipe MDN pour le contenu de MDN. Toute personne qui contribue à MDN se doit de respecter ces règles.

+ +

Pertinence

+ +

Le contenu de MDN doit être pertinent par rapport à la section dans laquelle il apparaît. Le spam et les publicités ou tout autre contenu inapproprié ne sera jamais accepté. Les personnes qui éditent afin d'ajouter ce type de contenu pourront être bannies sans avertissement.

+ +

Les liens sortants vers des sites commerciaux mais qui sont pertinents pour le sujet seront examinés au cas par cas. Leur valeur ajoutée à destination des développeuses et développeurs web doit dépasser le bénéfice commercial que tirera le site cible.

+ +

Neutralité

+ +

Le contenu d'un article de MDN doit conserver un point de vue neutre et les différences entre les navigateurs doivent être documentées sans biais. Les commentaires subjectifs et péjoratifs à propos d'un navigateur ou d'un agent utilisateur en particulier ne sont pas acceptables.

+ +

Web ouvert

+ +

MDN contient des documentations agnostiques aux différents navigateurs afin de permettre aux développeuses et développeurs web d'écrire du code qui fonctionne dans les différents navigateurs.

+ +

Les technologies documentées sur MDN doivent a minima être en voie de standardisation et être implémentée par au moins un navigateur. Les différences de compatibilité sont documentées dans les tableaux de compatibilité des articles.

+ +

Structure

+ +

Les pages de référence doivent suivre la même structure que les autres pages du même type. Voir les types de page pour une liste d'exemple des structures communément utilisées sur MDN.

+ +

Règles générales

+ +

Les contributrices et contributeurs doivent suivre les lignes directrices de MDN quant au style d'écriture, aux exemples de code, etc.

diff --git a/files/fr/mdn/guidelines/index.html b/files/fr/mdn/guidelines/index.html deleted file mode 100644 index 8b9ef2e3b1..0000000000 --- a/files/fr/mdn/guidelines/index.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Guides du style et du contenu MDN -slug: MDN/Guidelines -tags: - - Guidelines - - Landing - - MDN Meta -translation_of: MDN/Guidelines ---- -
{{MDNSidebar}}
- -

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 vous assurez que ce que vous produisez est propre et facile à utiliser.

- -

{{LandingPageListSubpages}}

diff --git a/files/fr/mdn/guidelines/index.md b/files/fr/mdn/guidelines/index.md new file mode 100644 index 0000000000..8b9ef2e3b1 --- /dev/null +++ b/files/fr/mdn/guidelines/index.md @@ -0,0 +1,14 @@ +--- +title: Guides du style et du contenu MDN +slug: MDN/Guidelines +tags: + - Guidelines + - Landing + - MDN Meta +translation_of: MDN/Guidelines +--- +
{{MDNSidebar}}
+ +

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 vous assurez que ce que vous produisez est propre et facile à utiliser.

+ +

{{LandingPageListSubpages}}

diff --git a/files/fr/mdn/guidelines/video/index.html b/files/fr/mdn/guidelines/video/index.html deleted file mode 100644 index 5cdc746163..0000000000 --- a/files/fr/mdn/guidelines/video/index.html +++ /dev/null @@ -1,230 +0,0 @@ ---- -title: Contenu vidéo sur MDN -slug: MDN/Guidelines/Video -tags: - - Guidelines - - Meta - - Video -translation_of: MDN/Guidelines/Video ---- -
{{MDNSidebar}}
- -

MDN n'est pas un site contenant beaucoup de vidéos. Toutefois, certaines documentations sont propices à ce type de média. Dans cet article, nous verrons quand inclure des vidéos sur MDN et quelques conseils permettant de créer des vidéos simples et efficaces.

- -

Quand utiliser des vidéos sur MDN

- -

L'utilisation de vidéo pour de la documentation technique n'est pas indiquée par défaut pour plusieurs raisons :

- - - -
-

Note : Il est important de garder ces limitations en tête lorsqu'on réalise des vidéos afin de les minimiser autant que possible.

-
- -

Il existe de nombreux sites populaires qui fournissent de nombreux tutoriels vidéo. MDN n'est pas un site dont la majorité du contenu est de la vidéo, toutefois, il est possible d'intégrer des vidéos dans certains articles MDN selon le contexte.

- -

Sur MDN, les vidéos sont particulièrement utilisées lorsqu'on souhaite décrire une suite d'instruction ou un procédé en plusieurs étapes qu'il serait difficile d'exprimer de façon concise avec du texte. Cela s'avère notamment utile lorsqu'on tente de décrire des procédés qui utilisent plusieurs applications ou fenêtres et qui incluent des interactions avec l'interface graphique qui pourraient ne pas être simples à décrire : « maintenant, cliquez sur le bouton situé en haut à gauche et qui ressemble à un canard ».

- -

Dans de telles situations, il est souvent plus pratique de montrer ce qu'on indique.

- -

À quoi doit ressembler une vidéo sur MDN ?

- -

Une vidéo à destination de MDN devrait être :

- - - -

Pour expliquer quelque chose de complexes, on pourra utiliser un ensemble de vidéos courtes et de captures d'écran avec du texte. Le texte permettra ainsi d'insister sur les notions vues dans les vidéos et la personne qui consulte le contenu pourra alors choisir de suivre le texte et/ou la vidéo.

- -

De plus, on fera attention aux conseils suivants :

- - - -

Outils

- -

Il vous faudra un outil pour enregistrer la vidéo. Il en existe une variété allant d'outils gratuits à payants, de simples à complexes. Si vous avez déjà créé du contenu vidéo : parfait. Sinon, nous vous conseillons de commencer avec un outil simple puis de choisir ensuite quelque chose de plus complexe si besoin.

- -

Le tableau qui suit fournit quelques recommandations d'outils pour commencer.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OutilSystème d'exploitationCoûtFonctionnalités de post-production ?
Open Broadcaster SoftwaremacOS, Windows, LinuxGratuitOui
CamStudioWindowsGratuitLimitées
CamtasiaWindows, macOSÉlevéOui
QuickTime PlayermacOSGratuitAucune
ScreenFlowmacOSIntermédiaireOui
KazamLinuxGratuitMinimales
- -

Conseils pour QuickTime

- -

Si vous utilisez macOS, Quicktime Player est disponible et dispose de quelques fonctionnalités pour l'enregistrement :

- -
    -
  1. Choisissez Fichier > Nouvel enregistrement d'écran à partir du menu principal.
    2. -
  2. Dans la boîte Enregistrement d'écran, utilisez le bouton d'enregistrement (le bouton rouge).
    3. -
  3. Dessinez un rectangle sur la zone de l'écran que vous souhaitez enregistrer.
    4. -
  4. Appuyez sur le bouton Démarrer l'enregistrement.
    5. -
  5. Effectuez les actions que vous souhaitez enregistrer.
    6. -
  6. Appuyez sur le bouton Stop.
    7. -
  7. Choisissez Fichier > Exporter en tant que… > 1080p à partir du menu principal afin d'avoir une définition suffisamment élevée.
    8. -
- -

Autres ressources

- - - -

Étapes de création d'une vidéo

- -

Les sections qui suivent décrivent les étapes principales à suivre pour créer une vidéo et l'intégrer à une page MDN.

- -

Préparation

- -

Tout d'abord, planifiez la suite d'actions que vous souhaitez enregistrer et choisissez les meilleures façons de commencer et de finir.

- -

Assurez vous que votre arrière-plan de bureau et votre profil de navigateur soient vierges. Planifier les tailles et le positionnement des fenêtres, notamment si vous utilisez plusieurs fenêtres.

- -

Planifiez soigneusement les étapes que vous allez enregistrer et pratiquez cette séquence d'actions plusieurs fois avant d'enregistrer :

- - - -
-

Note : Ne zoomez pas au point que les éléments d'interfaces soient déformés ou semblent étranges.

-
- -

Enregistrement

- -

Lorsque vous enregistrez, avancez dans les étapes de façon calme et régulière. Effectuez des pauses d'une seconde ou deux aux moments importants (lorsqu'il faut cliquer sur un bouton par exemple) et assurez vous que le pointeur de la souris n'occulte pas d'icône ou de texte important.

- -

N'oubliez pas de faire une pause d'une ou deux secondes à la fin pour montrer le résultat final de la séquence d'actions.

- -
-

Note : Si vous utilisez un outil simple comme QuickTime Player ou que vous ne pouvez pas effectuer de post-production, veillez à ce que la taille de la fenêtre soit de la bonne taille pour ce que vous voulez montrer.

-
- -

Post-production

- -

En post-production, vous pourrez mettre en avant certains éléments notamment grâce à :

- - - -

Mettez en avant les moments-clés et les détails difficiles à voir comme les clics sur une icône donnée ou la saisie d'une URL particulière. La mise en avant doit durer au moins 1 à 2 secondes et il sera généralement utile d'ajouter une courte transition (200 à 300 millisecondes) au début et à la fin de la mise en évidence.

- -

Attention à ne pas abuser de ces effets, on ne veut pas que les spectateurs aient le mal de mer à force de voir des zooms/dézooms.

- -

Si besoin, redimensionnez la vidéo aux proportions souhaitées.

- -

Upload

- -

Actuellement, les vidéos doivent être uploadées sur YouTube afin d'être affichées sur MDN.

- -
-

Note : Marquez la vidéo en « non répertoriée » si celle-ci n'a pas de sens particulier en dehors du contexte de la page MDN.

-
- -

Intégration

- -

Une fois la vidéo uploadée, vous pouvez intégrer la vidéo à la page avec la macro {{TemplateLink("EmbedYouTube")}}. Elle permet d'insérer la vidéo à l'emplacement de la macro :

- -

\{{EmbedYouTube("you-tube-url-slug")}}

- -

Cette macro utilise un seul argument qui correspond à la fin de l'URL de la vidéo. Ainsi, pour afficher la vidéo disponible à l'URL https://www.youtube.com/watch?v=ELS2OOUvxIw, on appellera la macro ainsi :

- -

\{{EmbedYouTube("ELS2OOUvxIw")}}

diff --git a/files/fr/mdn/guidelines/video/index.md b/files/fr/mdn/guidelines/video/index.md new file mode 100644 index 0000000000..5cdc746163 --- /dev/null +++ b/files/fr/mdn/guidelines/video/index.md @@ -0,0 +1,230 @@ +--- +title: Contenu vidéo sur MDN +slug: MDN/Guidelines/Video +tags: + - Guidelines + - Meta + - Video +translation_of: MDN/Guidelines/Video +--- +
{{MDNSidebar}}
+ +

MDN n'est pas un site contenant beaucoup de vidéos. Toutefois, certaines documentations sont propices à ce type de média. Dans cet article, nous verrons quand inclure des vidéos sur MDN et quelques conseils permettant de créer des vidéos simples et efficaces.

+ +

Quand utiliser des vidéos sur MDN

+ +

L'utilisation de vidéo pour de la documentation technique n'est pas indiquée par défaut pour plusieurs raisons :

+ + + +
+

Note : Il est important de garder ces limitations en tête lorsqu'on réalise des vidéos afin de les minimiser autant que possible.

+
+ +

Il existe de nombreux sites populaires qui fournissent de nombreux tutoriels vidéo. MDN n'est pas un site dont la majorité du contenu est de la vidéo, toutefois, il est possible d'intégrer des vidéos dans certains articles MDN selon le contexte.

+ +

Sur MDN, les vidéos sont particulièrement utilisées lorsqu'on souhaite décrire une suite d'instruction ou un procédé en plusieurs étapes qu'il serait difficile d'exprimer de façon concise avec du texte. Cela s'avère notamment utile lorsqu'on tente de décrire des procédés qui utilisent plusieurs applications ou fenêtres et qui incluent des interactions avec l'interface graphique qui pourraient ne pas être simples à décrire : « maintenant, cliquez sur le bouton situé en haut à gauche et qui ressemble à un canard ».

+ +

Dans de telles situations, il est souvent plus pratique de montrer ce qu'on indique.

+ +

À quoi doit ressembler une vidéo sur MDN ?

+ +

Une vidéo à destination de MDN devrait être :

+ + + +

Pour expliquer quelque chose de complexes, on pourra utiliser un ensemble de vidéos courtes et de captures d'écran avec du texte. Le texte permettra ainsi d'insister sur les notions vues dans les vidéos et la personne qui consulte le contenu pourra alors choisir de suivre le texte et/ou la vidéo.

+ +

De plus, on fera attention aux conseils suivants :

+ + + +

Outils

+ +

Il vous faudra un outil pour enregistrer la vidéo. Il en existe une variété allant d'outils gratuits à payants, de simples à complexes. Si vous avez déjà créé du contenu vidéo : parfait. Sinon, nous vous conseillons de commencer avec un outil simple puis de choisir ensuite quelque chose de plus complexe si besoin.

+ +

Le tableau qui suit fournit quelques recommandations d'outils pour commencer.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OutilSystème d'exploitationCoûtFonctionnalités de post-production ?
Open Broadcaster SoftwaremacOS, Windows, LinuxGratuitOui
CamStudioWindowsGratuitLimitées
CamtasiaWindows, macOSÉlevéOui
QuickTime PlayermacOSGratuitAucune
ScreenFlowmacOSIntermédiaireOui
KazamLinuxGratuitMinimales
+ +

Conseils pour QuickTime

+ +

Si vous utilisez macOS, Quicktime Player est disponible et dispose de quelques fonctionnalités pour l'enregistrement :

+ +
    +
  1. Choisissez Fichier > Nouvel enregistrement d'écran à partir du menu principal.
    2. +
  2. Dans la boîte Enregistrement d'écran, utilisez le bouton d'enregistrement (le bouton rouge).
    3. +
  3. Dessinez un rectangle sur la zone de l'écran que vous souhaitez enregistrer.
    4. +
  4. Appuyez sur le bouton Démarrer l'enregistrement.
    5. +
  5. Effectuez les actions que vous souhaitez enregistrer.
    6. +
  6. Appuyez sur le bouton Stop.
    7. +
  7. Choisissez Fichier > Exporter en tant que… > 1080p à partir du menu principal afin d'avoir une définition suffisamment élevée.
    8. +
+ +

Autres ressources

+ + + +

Étapes de création d'une vidéo

+ +

Les sections qui suivent décrivent les étapes principales à suivre pour créer une vidéo et l'intégrer à une page MDN.

+ +

Préparation

+ +

Tout d'abord, planifiez la suite d'actions que vous souhaitez enregistrer et choisissez les meilleures façons de commencer et de finir.

+ +

Assurez vous que votre arrière-plan de bureau et votre profil de navigateur soient vierges. Planifier les tailles et le positionnement des fenêtres, notamment si vous utilisez plusieurs fenêtres.

+ +

Planifiez soigneusement les étapes que vous allez enregistrer et pratiquez cette séquence d'actions plusieurs fois avant d'enregistrer :

+ + + +
+

Note : Ne zoomez pas au point que les éléments d'interfaces soient déformés ou semblent étranges.

+
+ +

Enregistrement

+ +

Lorsque vous enregistrez, avancez dans les étapes de façon calme et régulière. Effectuez des pauses d'une seconde ou deux aux moments importants (lorsqu'il faut cliquer sur un bouton par exemple) et assurez vous que le pointeur de la souris n'occulte pas d'icône ou de texte important.

+ +

N'oubliez pas de faire une pause d'une ou deux secondes à la fin pour montrer le résultat final de la séquence d'actions.

+ +
+

Note : Si vous utilisez un outil simple comme QuickTime Player ou que vous ne pouvez pas effectuer de post-production, veillez à ce que la taille de la fenêtre soit de la bonne taille pour ce que vous voulez montrer.

+
+ +

Post-production

+ +

En post-production, vous pourrez mettre en avant certains éléments notamment grâce à :

+ + + +

Mettez en avant les moments-clés et les détails difficiles à voir comme les clics sur une icône donnée ou la saisie d'une URL particulière. La mise en avant doit durer au moins 1 à 2 secondes et il sera généralement utile d'ajouter une courte transition (200 à 300 millisecondes) au début et à la fin de la mise en évidence.

+ +

Attention à ne pas abuser de ces effets, on ne veut pas que les spectateurs aient le mal de mer à force de voir des zooms/dézooms.

+ +

Si besoin, redimensionnez la vidéo aux proportions souhaitées.

+ +

Upload

+ +

Actuellement, les vidéos doivent être uploadées sur YouTube afin d'être affichées sur MDN.

+ +
+

Note : Marquez la vidéo en « non répertoriée » si celle-ci n'a pas de sens particulier en dehors du contexte de la page MDN.

+
+ +

Intégration

+ +

Une fois la vidéo uploadée, vous pouvez intégrer la vidéo à la page avec la macro {{TemplateLink("EmbedYouTube")}}. Elle permet d'insérer la vidéo à l'emplacement de la macro :

+ +

\{{EmbedYouTube("you-tube-url-slug")}}

+ +

Cette macro utilise un seul argument qui correspond à la fin de l'URL de la vidéo. Ainsi, pour afficher la vidéo disponible à l'URL https://www.youtube.com/watch?v=ELS2OOUvxIw, on appellera la macro ainsi :

+ +

\{{EmbedYouTube("ELS2OOUvxIw")}}

diff --git a/files/fr/mdn/guidelines/writing_style_guide/index.html b/files/fr/mdn/guidelines/writing_style_guide/index.html deleted file mode 100644 index 348cec2bc7..0000000000 --- a/files/fr/mdn/guidelines/writing_style_guide/index.html +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: Guide stylistique -slug: MDN/Guidelines/Writing_style_guide -tags: - - Documentation - - Guide - - Guidelines - - MDN - - MDN Meta - - MDN Web Docs - - MDN style guide - - Style guide - - Writing style guide -translation_of: MDN/Guidelines/Writing_style_guide ---- -
{{MDNSidebar}}
- -

Afin de présenter la documentation de façon organisée, cohérente et facile à lire, le guide stylistique de MDN décrit la façon dont le texte doit être organisé, orthographié, mis en forme, etc. Il s'agit ici de règles générales plutôt que de consignes strictes. Le contenu importe plus que la forme et il n'y a pas d'obligation à apprendre ce guide avant de contribuer. Toutefois, ne soyez pas surpris⋅e si une contributrice ou un contributeur édite une de vos éditions pour respecter ce guide.

- -

La suite de ce guide vise avant tout la documentation francophone. Elle reprend des parties du guide stylistique anglophone lorsque c'est pertinent. Vous pouvez également consulter le guide stylistique de la communauté francophone. Si vous souhaitez contribuer au contenu en anglais, rapportez vous au guide stylistique anglophone.

- -

Règles de base

- -

Voici quelques règles simples qui permettent de conserver une cohérence dans la documentation.

- -

Titres des pages

- -

Les titres des pages sont utilisés dans les résultats des recherches et affichés dans les fils d'Ariane en haut de la page. Le titre de la page pourra être différent de la partie d'URL du document. En français, il devra l'être (car le fragment d'URL sera anglophone).

- -

Titres et capitales

- -

Seul le premier terme d'un titre (de page ou de section) devra être en capitale :

- - - -

Si vous voyez certains titres qui enfreignent cette règle, n'hésitez pas à contribuer pour les corriger.

- -

Choix des titres

- -

Contrairement au fragment d'URL de la page (court et fixé par la version anglophone), on pourra choisir un titre descriptif suffisamment long.

- -

Création de nouvelles pages

- -

Le contenu francophone « suit » le contenu anglophone. Toute nouvelle page de MDN devra d'abord être créée avec sa version anglaise avant d'être traduite.

- -

Style et mise en forme des exemples de code

- -

On pourra traduire les noms de certaines variables pour les franciser (par exemple toto à la place de foo) et on traduira les commentaires

- -

Sauts de ligne

- -

Pour un fragment de code, on évitera d'avoir une ligne trop longue qui nécessite de faire défiler le contenu horizontal. On privilégiera les ruptures de lignes naturelles :

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

Abréviations

- -
-

Note : les abréviations sont à utiliser à bon escient et il faudra bien connaître leur sens (notamment pour les abrévations latines) afin de les utiliser correctement. Il faut être conscient que leur usage peut être source de confusion pour les lectrices et lecteurs qui pourraient ne pas y être habitués.

-
- -

Dans les notes et parenthèses

- -

Les abréviations communes (etc., i.e.) pourront être utilisées dans les notes et entre parenthèses. Attention, on utilisera ex. plutôt que e.g. qui est usité en anglais (ou que p. ex. qui est moins usité).

- -

Dans le texte

- - - - -

Acronymes et abréviations

- -

Capitalisation et usage des points

- -

Les acronymes seront écrits en capitales et sans point.

- - - -

Explication

- -

Lors de la première mention d'un terme abrégé sur une page, on expliquera l'acronyme et/ou on liera vers le glossaire.

- -

Pluriels des acronymes

- -

Contrairement aux pratiques anglophones, on n'apportera pas de s pour les formes plurielles des acronymes.

- - - -

Ponctuation

- -

Apostrophes et guillemets

- -

On n'utilisera pas d'apostrophe courbe sur MDN. L'usage des guillemets français est autorisé (mais pas obligatoire) et ceux-ci ne doivent pas servir dans du code pour délimiter des chaînes de caractères où il faudra utiliser les doubles quotes.

- -

Orthographe

- -

On recommandera l'utilisation de Grammalecte pour vérifier l'orthographe d'un document.

- -

Terminologie

- -

En cas de doute sur la formulation en français d'un terme ou d'une expression anglaise, on privilégiera l'usage, Transvision, Wikipédia.

\ No newline at end of file diff --git a/files/fr/mdn/guidelines/writing_style_guide/index.md b/files/fr/mdn/guidelines/writing_style_guide/index.md new file mode 100644 index 0000000000..348cec2bc7 --- /dev/null +++ b/files/fr/mdn/guidelines/writing_style_guide/index.md @@ -0,0 +1,124 @@ +--- +title: Guide stylistique +slug: MDN/Guidelines/Writing_style_guide +tags: + - Documentation + - Guide + - Guidelines + - MDN + - MDN Meta + - MDN Web Docs + - MDN style guide + - Style guide + - Writing style guide +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +

Afin de présenter la documentation de façon organisée, cohérente et facile à lire, le guide stylistique de MDN décrit la façon dont le texte doit être organisé, orthographié, mis en forme, etc. Il s'agit ici de règles générales plutôt que de consignes strictes. Le contenu importe plus que la forme et il n'y a pas d'obligation à apprendre ce guide avant de contribuer. Toutefois, ne soyez pas surpris⋅e si une contributrice ou un contributeur édite une de vos éditions pour respecter ce guide.

+ +

La suite de ce guide vise avant tout la documentation francophone. Elle reprend des parties du guide stylistique anglophone lorsque c'est pertinent. Vous pouvez également consulter le guide stylistique de la communauté francophone. Si vous souhaitez contribuer au contenu en anglais, rapportez vous au guide stylistique anglophone.

+ +

Règles de base

+ +

Voici quelques règles simples qui permettent de conserver une cohérence dans la documentation.

+ +

Titres des pages

+ +

Les titres des pages sont utilisés dans les résultats des recherches et affichés dans les fils d'Ariane en haut de la page. Le titre de la page pourra être différent de la partie d'URL du document. En français, il devra l'être (car le fragment d'URL sera anglophone).

+ +

Titres et capitales

+ +

Seul le premier terme d'un titre (de page ou de section) devra être en capitale :

+ + + +

Si vous voyez certains titres qui enfreignent cette règle, n'hésitez pas à contribuer pour les corriger.

+ +

Choix des titres

+ +

Contrairement au fragment d'URL de la page (court et fixé par la version anglophone), on pourra choisir un titre descriptif suffisamment long.

+ +

Création de nouvelles pages

+ +

Le contenu francophone « suit » le contenu anglophone. Toute nouvelle page de MDN devra d'abord être créée avec sa version anglaise avant d'être traduite.

+ +

Style et mise en forme des exemples de code

+ +

On pourra traduire les noms de certaines variables pour les franciser (par exemple toto à la place de foo) et on traduira les commentaires

+ +

Sauts de ligne

+ +

Pour un fragment de code, on évitera d'avoir une ligne trop longue qui nécessite de faire défiler le contenu horizontal. On privilégiera les ruptures de lignes naturelles :

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

Abréviations

+ +
+

Note : les abréviations sont à utiliser à bon escient et il faudra bien connaître leur sens (notamment pour les abrévations latines) afin de les utiliser correctement. Il faut être conscient que leur usage peut être source de confusion pour les lectrices et lecteurs qui pourraient ne pas y être habitués.

+
+ +

Dans les notes et parenthèses

+ +

Les abréviations communes (etc., i.e.) pourront être utilisées dans les notes et entre parenthèses. Attention, on utilisera ex. plutôt que e.g. qui est usité en anglais (ou que p. ex. qui est moins usité).

+ +

Dans le texte

+ + + + +

Acronymes et abréviations

+ +

Capitalisation et usage des points

+ +

Les acronymes seront écrits en capitales et sans point.

+ + + +

Explication

+ +

Lors de la première mention d'un terme abrégé sur une page, on expliquera l'acronyme et/ou on liera vers le glossaire.

+ +

Pluriels des acronymes

+ +

Contrairement aux pratiques anglophones, on n'apportera pas de s pour les formes plurielles des acronymes.

+ + + +

Ponctuation

+ +

Apostrophes et guillemets

+ +

On n'utilisera pas d'apostrophe courbe sur MDN. L'usage des guillemets français est autorisé (mais pas obligatoire) et ceux-ci ne doivent pas servir dans du code pour délimiter des chaînes de caractères où il faudra utiliser les doubles quotes.

+ +

Orthographe

+ +

On recommandera l'utilisation de Grammalecte pour vérifier l'orthographe d'un document.

+ +

Terminologie

+ +

En cas de doute sur la formulation en français d'un terme ou d'une expression anglaise, on privilégiera l'usage, Transvision, Wikipédia.

\ No newline at end of file diff --git a/files/fr/mdn/index.html b/files/fr/mdn/index.html deleted file mode 100644 index 9ba60b7b63..0000000000 --- a/files/fr/mdn/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -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/index.md b/files/fr/mdn/index.md new file mode 100644 index 0000000000..9ba60b7b63 --- /dev/null +++ b/files/fr/mdn/index.md @@ -0,0 +1,35 @@ +--- +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/structures/index.html b/files/fr/mdn/structures/index.html deleted file mode 100644 index 5e605bea37..0000000000 --- a/files/fr/mdn/structures/index.html +++ /dev/null @@ -1,17 +0,0 @@ ---- -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/index.md b/files/fr/mdn/structures/index.md new file mode 100644 index 0000000000..5e605bea37 --- /dev/null +++ b/files/fr/mdn/structures/index.md @@ -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/live_samples/index.html b/files/fr/mdn/structures/live_samples/index.html deleted file mode 100644 index c297eac680..0000000000 --- a/files/fr/mdn/structures/live_samples/index.html +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: Exemples live -slug: MDN/Structures/Live_samples -tags: - - Guide - - Intermediate - - MDN Meta - - Structures -translation_of: MDN/Structures/Live_samples -original_slug: MDN/Structures/Exemples_live ---- -
{{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 interactifs ; 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 <iframe>. Un exemple live est composé de deux parties :

- - - -

Dans ce contexte, un « groupe » de blocs de code est identifié par l'ID d'un titre ou d'un élément de bloc (tel qu'un <div>).

- - - -

La macro utilise une URL spéciale pour récupérer l'échantillon de code pour un groupe donné, par exemple https://yari-demos.prod.mdn.mozit.cloud/en-US/docs/Web/CSS/animation/_samples_/Cylon_Eye. La structure générale est https://url-of-page_samples_/group-id, où group-id est l'ID de la rubrique ou du bloc où se trouve le code.

- -

Le cadre (ou la page) qui en résulte est protégé par un bac à sable, sécurisé, et peut techniquement faire tout ce qui fonctionne sur le Web. Bien sûr, d'un point de vue pratique, le code doit contribuer à l'intérêt de la page qui le contient ; les trucs aléatoires qui tournent sur MDN seront supprimés par la communauté des éditeurs.

- -
-

Note : Vous devez utiliser la macro pour présenter la sortie de l'échantillon en direct.

-
- -

Chaque bloc <pre> contenant du code pour l'échantillon est doté d'une classe qui indique s'il s'agit de code HTML, CSS ou JavaScript ; ces classes sont « brush : html », « brush : css » et « brush : js ». Ces classes doivent se trouver sur les blocs de code correspondants.

- -

Le système d'échantillonnage en direct offre de nombreuses options, et nous allons essayer de les décomposer pour les examiner un par un.

- -

Exemples de macros en direct

- -

Il existe deux macros que vous pouvez utiliser pour afficher des échantillons en direct :

- - - -

Dans de nombreux cas, vous pouvez être en mesure d'ajouter la macro EmbedLiveSample ou LiveSampleLink aux pages avec peu ou pas de travail supplémentaire ! Tant que l'échantillon peut être identifié par l'ID d'un titre ou se trouve dans un bloc avec un ID que vous pouvez utiliser, l'ajout de la macro devrait faire l'affaire.

- -

La macro EmbedLiveSample

- -
\{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
- -
-
block_ID
-
Requis : L'ID de l'en-tête ou du bloc qui l'entoure d'où le code doit être tiré. La meilleure façon de s'assurer que l'ID est correct est de regarder l'URL de la section dans la table des matières de la page ; vous pouvez également le vérifier en consultant le source de la page.
-
width
-
La largeur de l'<iframe> à créer, spécifiée en px. Ce paramètre est facultatif ; une largeur par défaut raisonnable sera utilisée si vous l'omettez. Notez que si vous voulez utiliser une largeur spécifique, vous devez également spécifier le paramètre height.
-
height
-
La hauteur de l'<iframe> à créer, spécifiée en px. Ce paramètre est facultatif ; une hauteur par défaut raisonnable sera utilisée si vous l'omettez. Notez que si vous voulez utiliser une hauteur spécifique, vous devez également spécifier le paramètre width. Si vous n'utilisez qu'un seul d'entre eux, la taille de cadre par défaut est utilisée.
-
screenshot_URL
-
L'URL d'une capture d'écran qui montre à quoi devrait ressembler l'échantillon en direct. Ce paramètre est facultatif, mais il peut être utile pour les nouvelles technologies qui ne fonctionnent peut-être pas dans le navigateur de l'utilisateur, afin qu'il puisse voir à quoi ressemblerait l'échantillon s'il était pris en charge par son navigateur. Si vous incluez ce paramètre, la capture d'écran est affichée à côté de l'échantillon en direct, avec les titres appropriés.
-
page_slug
-
-

Le slug de la page contenant l'échantillon ; ceci est facultatif, et s'il n'est pas fourni, l'échantillon est tiré de la même page sur laquelle la macro est utilisée.

-
-

Attention : Pour afficher un échantillon en direct d'une page contenant du code dans une page cible différente, la page contenant du code doit elle-même utiliser la macro EmbedLiveSample pour intégrer un échantillon en direct dans sa propre page. Sinon, si la page contenant le code n'utilise pas elle-même la macro EmbedLiveSample sa propre page, l'échantillon vivant ne s'affichera pas du tout sur la page cible. (Voir Le ticket Yari #2243.)

-
-
-
- - - -
\{{LiveSampleLink(block_ID, link_text)}}
- -
-
block_ID
-
L'ID de l'en-tête ou du bloc qui l'entoure, d'où le code doit être tiré. La meilleure façon de s'assurer que l'ID est correct est de regarder l'URL de la section dans la table des matières de la page ; vous pouvez également le vérifier en consultant le source de la page.
-
link_text
-
Une chaîne de caractères à utiliser comme texte du lien.
-
- -

Utilisation du système d'échantillonnage en direct

- -

Les sections ci-dessous décrivent quelques cas d'utilisation courants du système d'échantillons en direct.

- -

Transformer des extraits en échantillons vivants

- -

Un cas d'utilisation courant consiste à prendre des extraits de code existants déjà présentés sur MDN et à les transformer en échantillons vivants.

- -

Préparer les échantillons de code

- -

La première étape consiste à ajouter des extraits de code ou à s'assurer que les extraits existants sont prêts à être utilisés comme échantillons en direct, tant au niveau du contenu que du balisage. Les extraits de code, pris dans leur ensemble, doivent constituer un exemple complet et exécutable. Par exemple, si l'extrait existant ne présente que du CSS, vous devrez peut-être ajouter un extrait de HTML sur lequel le CSS pourra opérer.

- -

Chaque morceau de code doit se trouver dans un bloc <pre>, avec un bloc distinct pour chaque langue, correctement marqué quant à sa langue. La plupart du temps, cela a déjà été fait, mais il est toujours utile de revérifier pour s'assurer que chaque morceau de code est configuré avec la bonne syntaxe. Ceci est fait avec une classe sur l'élément <pre> de brush:language-type, où language-type est le type de langage que le bloc contient, par exemple html, css, ou js.

- -
-

Note : Vous pouvez avoir plus d'un bloc pour chaque langue ; ils sont tous concaténés ensemble. Vous pouvez ainsi avoir un morceau de code, suivi d'une explication de son fonctionnement, puis un autre morceau, et ainsi de suite. Il est ainsi encore plus facile de produire des didacticiels et autres qui utilisent des échantillons en direct entrecoupés de texte explicatif.

-
- -

Assurez-vous donc que les blocs <pre> de votre code HTML, CSS et/ou JavaScript sont chacun configurés correctement pour la coloration syntaxique de ce langage, et vous êtes prêt à partir.

- -

Démonstration en direct

- -

Cette section est le résultat de l'utilisation du bouton du modèle d'échantillon en direct pour créer non seulement le titre principal (« Démonstration d'échantillon en direct »), mais aussi des sous-titres pour notre contenu HTML, CSS et JavaScript. Vous n'êtes pas limité à un bloc de chacun d'entre eux ; en outre, ils ne doivent pas nécessairement être dans un ordre particulier. Mélangez et associez !

- -

Vous pouvez choisir de supprimer tous ceux que vous souhaitez ; si vous n'avez pas besoin de script, supprimez simplement cette rubrique et son bloc <pre>. Vous pouvez également supprimer l'intitulé d'un bloc de code (« HTML », « CSS » ou « JavaScript »), puisqu'il n'est pas utilisé par la macro d'échantillonnage en direct.

- -

Maintenant que le modèle a été inséré, nous pouvons insérer du code, voire du texte explicatif.

- -

HTML

- -

Ce HTML crée un paragraphe et quelques blocs pour nous aider à positionner et à styliser un message.

- -
<p>Un exemple simple du système d'échantillonnage en direct en action.</p>
-<div class="box">
-  <div id="item">Bonjour à tous ! Bienvenue sur MDN</div>
-</div>
- -

CSS

- -

Le code CSS donne un style à la boîte ainsi qu'au texte qu'elle contient.

- -
.box {
-  width: 200px;
-  border-radius: 6px;
-  padding: 20px;
-  background-color: #ffaabb;
-}
-
-#item {
-  font-weight: bold;
-  text-align: center;
-  font-family: sans-serif;
-  font-size: 1.5em;
-}
- -

JavaScript

- -

Ce code est très simple. Tout ce qu'il fait est d'attacher un gestionnaire d'événement au texte « Bonjour à tous ! » qui fait apparaître une alerte lorsqu'il est cliqué.

- -
const el = document.getElementById('item');
-el.onclick = function() {
-  alert('Ohhh, arrête de m\'embêter !');
-}
- -

Résultat

- -

Voici le résultat de l'exécution des blocs de code ci-dessus via \{{EmbedLiveSample('live_sample_demo')}} :

- -

{{EmbedLiveSample('live_sample_demo')}}

- -

Voici un lien qui résulte de l'appel de ces blocs de code via \{{LiveSampleLink('live_sample_demo', 'Lien vers un échantillon de démonstration en direct')}}:

- -

{{LiveSampleLink('live_sample_demo', 'Lien vers un échantillon de démonstration en direct')}}

- -

Conventions relatives aux échantillons vivants

- -
-
Ordres des blocs de code
-
Lors de l'ajout d'un échantillon vivant, les blocs de code doivent être triés de manière à ce que le premier corresponde à la langue principale de cet échantillon (s'il y en a une). Par exemple, lors de l'ajout d'un échantillon réel pour la référence HTML, le premier bloc doit être HTML, lors de l'ajout d'un échantillon réel pour la référence CSS, il doit être CSS et ainsi de suite.
-
Nomenclature des rubriques
-
Lorsqu'il n'y a pas d'ambiguïté (par exemple, l'échantillon se trouve dans une section « Exemples »), les titres doivent être simples avec le seul nom du langage correspondant : HTML, CSS, JavaScript, SVG, etc. (voir ci-dessus). Les titres tels que « Contenu HTML » ou « Contenu JavaScript » ne doivent pas être utilisés. Toutefois, si un titre aussi court rend le contenu peu clair, on peut utiliser un titre plus réfléchi.
-
Utilisation d'un bloc « Résultat »
-
Après les différents blocs de code, veuillez utiliser un dernier bloc « Résultat » avant d'utiliser la macro EmbedLiveSample (voir ci-dessus). De cette façon, la sémantique de l'exemple est rendue plus claire à la fois pour le lecteur et pour tout outil qui analyserait la page (par exemple, un lecteur d'écran, un crawler web).
-
diff --git a/files/fr/mdn/structures/live_samples/index.md b/files/fr/mdn/structures/live_samples/index.md new file mode 100644 index 0000000000..c297eac680 --- /dev/null +++ b/files/fr/mdn/structures/live_samples/index.md @@ -0,0 +1,171 @@ +--- +title: Exemples live +slug: MDN/Structures/Live_samples +tags: + - Guide + - Intermediate + - MDN Meta + - Structures +translation_of: MDN/Structures/Live_samples +original_slug: MDN/Structures/Exemples_live +--- +
{{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 interactifs ; 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 <iframe>. Un exemple live est composé de deux parties :

+ + + +

Dans ce contexte, un « groupe » de blocs de code est identifié par l'ID d'un titre ou d'un élément de bloc (tel qu'un <div>).

+ + + +

La macro utilise une URL spéciale pour récupérer l'échantillon de code pour un groupe donné, par exemple https://yari-demos.prod.mdn.mozit.cloud/en-US/docs/Web/CSS/animation/_samples_/Cylon_Eye. La structure générale est https://url-of-page_samples_/group-id, où group-id est l'ID de la rubrique ou du bloc où se trouve le code.

+ +

Le cadre (ou la page) qui en résulte est protégé par un bac à sable, sécurisé, et peut techniquement faire tout ce qui fonctionne sur le Web. Bien sûr, d'un point de vue pratique, le code doit contribuer à l'intérêt de la page qui le contient ; les trucs aléatoires qui tournent sur MDN seront supprimés par la communauté des éditeurs.

+ +
+

Note : Vous devez utiliser la macro pour présenter la sortie de l'échantillon en direct.

+
+ +

Chaque bloc <pre> contenant du code pour l'échantillon est doté d'une classe qui indique s'il s'agit de code HTML, CSS ou JavaScript ; ces classes sont « brush : html », « brush : css » et « brush : js ». Ces classes doivent se trouver sur les blocs de code correspondants.

+ +

Le système d'échantillonnage en direct offre de nombreuses options, et nous allons essayer de les décomposer pour les examiner un par un.

+ +

Exemples de macros en direct

+ +

Il existe deux macros que vous pouvez utiliser pour afficher des échantillons en direct :

+ + + +

Dans de nombreux cas, vous pouvez être en mesure d'ajouter la macro EmbedLiveSample ou LiveSampleLink aux pages avec peu ou pas de travail supplémentaire ! Tant que l'échantillon peut être identifié par l'ID d'un titre ou se trouve dans un bloc avec un ID que vous pouvez utiliser, l'ajout de la macro devrait faire l'affaire.

+ +

La macro EmbedLiveSample

+ +
\{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
+ +
+
block_ID
+
Requis : L'ID de l'en-tête ou du bloc qui l'entoure d'où le code doit être tiré. La meilleure façon de s'assurer que l'ID est correct est de regarder l'URL de la section dans la table des matières de la page ; vous pouvez également le vérifier en consultant le source de la page.
+
width
+
La largeur de l'<iframe> à créer, spécifiée en px. Ce paramètre est facultatif ; une largeur par défaut raisonnable sera utilisée si vous l'omettez. Notez que si vous voulez utiliser une largeur spécifique, vous devez également spécifier le paramètre height.
+
height
+
La hauteur de l'<iframe> à créer, spécifiée en px. Ce paramètre est facultatif ; une hauteur par défaut raisonnable sera utilisée si vous l'omettez. Notez que si vous voulez utiliser une hauteur spécifique, vous devez également spécifier le paramètre width. Si vous n'utilisez qu'un seul d'entre eux, la taille de cadre par défaut est utilisée.
+
screenshot_URL
+
L'URL d'une capture d'écran qui montre à quoi devrait ressembler l'échantillon en direct. Ce paramètre est facultatif, mais il peut être utile pour les nouvelles technologies qui ne fonctionnent peut-être pas dans le navigateur de l'utilisateur, afin qu'il puisse voir à quoi ressemblerait l'échantillon s'il était pris en charge par son navigateur. Si vous incluez ce paramètre, la capture d'écran est affichée à côté de l'échantillon en direct, avec les titres appropriés.
+
page_slug
+
+

Le slug de la page contenant l'échantillon ; ceci est facultatif, et s'il n'est pas fourni, l'échantillon est tiré de la même page sur laquelle la macro est utilisée.

+
+

Attention : Pour afficher un échantillon en direct d'une page contenant du code dans une page cible différente, la page contenant du code doit elle-même utiliser la macro EmbedLiveSample pour intégrer un échantillon en direct dans sa propre page. Sinon, si la page contenant le code n'utilise pas elle-même la macro EmbedLiveSample sa propre page, l'échantillon vivant ne s'affichera pas du tout sur la page cible. (Voir Le ticket Yari #2243.)

+
+
+
+ + + +
\{{LiveSampleLink(block_ID, link_text)}}
+ +
+
block_ID
+
L'ID de l'en-tête ou du bloc qui l'entoure, d'où le code doit être tiré. La meilleure façon de s'assurer que l'ID est correct est de regarder l'URL de la section dans la table des matières de la page ; vous pouvez également le vérifier en consultant le source de la page.
+
link_text
+
Une chaîne de caractères à utiliser comme texte du lien.
+
+ +

Utilisation du système d'échantillonnage en direct

+ +

Les sections ci-dessous décrivent quelques cas d'utilisation courants du système d'échantillons en direct.

+ +

Transformer des extraits en échantillons vivants

+ +

Un cas d'utilisation courant consiste à prendre des extraits de code existants déjà présentés sur MDN et à les transformer en échantillons vivants.

+ +

Préparer les échantillons de code

+ +

La première étape consiste à ajouter des extraits de code ou à s'assurer que les extraits existants sont prêts à être utilisés comme échantillons en direct, tant au niveau du contenu que du balisage. Les extraits de code, pris dans leur ensemble, doivent constituer un exemple complet et exécutable. Par exemple, si l'extrait existant ne présente que du CSS, vous devrez peut-être ajouter un extrait de HTML sur lequel le CSS pourra opérer.

+ +

Chaque morceau de code doit se trouver dans un bloc <pre>, avec un bloc distinct pour chaque langue, correctement marqué quant à sa langue. La plupart du temps, cela a déjà été fait, mais il est toujours utile de revérifier pour s'assurer que chaque morceau de code est configuré avec la bonne syntaxe. Ceci est fait avec une classe sur l'élément <pre> de brush:language-type, où language-type est le type de langage que le bloc contient, par exemple html, css, ou js.

+ +
+

Note : Vous pouvez avoir plus d'un bloc pour chaque langue ; ils sont tous concaténés ensemble. Vous pouvez ainsi avoir un morceau de code, suivi d'une explication de son fonctionnement, puis un autre morceau, et ainsi de suite. Il est ainsi encore plus facile de produire des didacticiels et autres qui utilisent des échantillons en direct entrecoupés de texte explicatif.

+
+ +

Assurez-vous donc que les blocs <pre> de votre code HTML, CSS et/ou JavaScript sont chacun configurés correctement pour la coloration syntaxique de ce langage, et vous êtes prêt à partir.

+ +

Démonstration en direct

+ +

Cette section est le résultat de l'utilisation du bouton du modèle d'échantillon en direct pour créer non seulement le titre principal (« Démonstration d'échantillon en direct »), mais aussi des sous-titres pour notre contenu HTML, CSS et JavaScript. Vous n'êtes pas limité à un bloc de chacun d'entre eux ; en outre, ils ne doivent pas nécessairement être dans un ordre particulier. Mélangez et associez !

+ +

Vous pouvez choisir de supprimer tous ceux que vous souhaitez ; si vous n'avez pas besoin de script, supprimez simplement cette rubrique et son bloc <pre>. Vous pouvez également supprimer l'intitulé d'un bloc de code (« HTML », « CSS » ou « JavaScript »), puisqu'il n'est pas utilisé par la macro d'échantillonnage en direct.

+ +

Maintenant que le modèle a été inséré, nous pouvons insérer du code, voire du texte explicatif.

+ +

HTML

+ +

Ce HTML crée un paragraphe et quelques blocs pour nous aider à positionner et à styliser un message.

+ +
<p>Un exemple simple du système d'échantillonnage en direct en action.</p>
+<div class="box">
+  <div id="item">Bonjour à tous ! Bienvenue sur MDN</div>
+</div>
+ +

CSS

+ +

Le code CSS donne un style à la boîte ainsi qu'au texte qu'elle contient.

+ +
.box {
+  width: 200px;
+  border-radius: 6px;
+  padding: 20px;
+  background-color: #ffaabb;
+}
+
+#item {
+  font-weight: bold;
+  text-align: center;
+  font-family: sans-serif;
+  font-size: 1.5em;
+}
+ +

JavaScript

+ +

Ce code est très simple. Tout ce qu'il fait est d'attacher un gestionnaire d'événement au texte « Bonjour à tous ! » qui fait apparaître une alerte lorsqu'il est cliqué.

+ +
const el = document.getElementById('item');
+el.onclick = function() {
+  alert('Ohhh, arrête de m\'embêter !');
+}
+ +

Résultat

+ +

Voici le résultat de l'exécution des blocs de code ci-dessus via \{{EmbedLiveSample('live_sample_demo')}} :

+ +

{{EmbedLiveSample('live_sample_demo')}}

+ +

Voici un lien qui résulte de l'appel de ces blocs de code via \{{LiveSampleLink('live_sample_demo', 'Lien vers un échantillon de démonstration en direct')}}:

+ +

{{LiveSampleLink('live_sample_demo', 'Lien vers un échantillon de démonstration en direct')}}

+ +

Conventions relatives aux échantillons vivants

+ +
+
Ordres des blocs de code
+
Lors de l'ajout d'un échantillon vivant, les blocs de code doivent être triés de manière à ce que le premier corresponde à la langue principale de cet échantillon (s'il y en a une). Par exemple, lors de l'ajout d'un échantillon réel pour la référence HTML, le premier bloc doit être HTML, lors de l'ajout d'un échantillon réel pour la référence CSS, il doit être CSS et ainsi de suite.
+
Nomenclature des rubriques
+
Lorsqu'il n'y a pas d'ambiguïté (par exemple, l'échantillon se trouve dans une section « Exemples »), les titres doivent être simples avec le seul nom du langage correspondant : HTML, CSS, JavaScript, SVG, etc. (voir ci-dessus). Les titres tels que « Contenu HTML » ou « Contenu JavaScript » ne doivent pas être utilisés. Toutefois, si un titre aussi court rend le contenu peu clair, on peut utiliser un titre plus réfléchi.
+
Utilisation d'un bloc « Résultat »
+
Après les différents blocs de code, veuillez utiliser un dernier bloc « Résultat » avant d'utiliser la macro EmbedLiveSample (voir ci-dessus). De cette façon, la sémantique de l'exemple est rendue plus claire à la fois pour le lecteur et pour tout outil qui analyserait la page (par exemple, un lecteur d'écran, un crawler web).
+
diff --git a/files/fr/mdn/structures/macros/commonly-used_macros/index.html b/files/fr/mdn/structures/macros/commonly-used_macros/index.html deleted file mode 100644 index 4aaeb81c61..0000000000 --- a/files/fr/mdn/structures/macros/commonly-used_macros/index.html +++ /dev/null @@ -1,208 +0,0 @@ ---- -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.

- -
    -
- -

 

- -
    -
- -

 

diff --git a/files/fr/mdn/structures/macros/commonly-used_macros/index.md b/files/fr/mdn/structures/macros/commonly-used_macros/index.md new file mode 100644 index 0000000000..4aaeb81c61 --- /dev/null +++ b/files/fr/mdn/structures/macros/commonly-used_macros/index.md @@ -0,0 +1,208 @@ +--- +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.

+ +
    +
+ +

 

+ +
    +
+ +

 

diff --git a/files/fr/mdn/structures/macros/index.html b/files/fr/mdn/structures/macros/index.html deleted file mode 100644 index 448d6a4649..0000000000 --- a/files/fr/mdn/structures/macros/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -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.

- -
-

Note : 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/macros/index.md b/files/fr/mdn/structures/macros/index.md new file mode 100644 index 0000000000..448d6a4649 --- /dev/null +++ b/files/fr/mdn/structures/macros/index.md @@ -0,0 +1,41 @@ +--- +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.

+ +
+

Note : 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/tools/index.html b/files/fr/mdn/tools/index.html deleted file mode 100644 index 340603eece..0000000000 --- a/files/fr/mdn/tools/index.html +++ /dev/null @@ -1,16 +0,0 @@ ---- -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/index.md b/files/fr/mdn/tools/index.md new file mode 100644 index 0000000000..340603eece --- /dev/null +++ b/files/fr/mdn/tools/index.md @@ -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/yari/index.html b/files/fr/mdn/yari/index.html deleted file mode 100644 index b75fe1b8ef..0000000000 --- a/files/fr/mdn/yari/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Kuma, la plateforme soutenant le wiki MDN -slug: MDN/Yari -tags: - - Kuma - - Kuma script - - MDN Meta -translation_of: MDN/Kuma -original_slug: 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/yari/index.md b/files/fr/mdn/yari/index.md new file mode 100644 index 0000000000..b75fe1b8ef --- /dev/null +++ b/files/fr/mdn/yari/index.md @@ -0,0 +1,25 @@ +--- +title: Kuma, la plateforme soutenant le wiki MDN +slug: MDN/Yari +tags: + - Kuma + - Kuma script + - MDN Meta +translation_of: MDN/Kuma +original_slug: 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 :

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