From abfd01f42c355d2212d1a8e0d6aca85037ce4139 Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 11 Nov 2021 06:45:27 +0100 Subject: convert content to md --- files/fr/mdn/about/index.md | 28 +- files/fr/mdn/at_ten/history_of_mdn/index.md | 208 ++++--- files/fr/mdn/at_ten/index.md | 30 +- .../contribute/documentation_priorities/index.md | 387 ++++++------ files/fr/mdn/contribute/feedback/index.md | 64 +- files/fr/mdn/contribute/getting_started/index.md | 53 +- files/fr/mdn/contribute/github_beginners/index.md | 676 ++++++++++----------- .../mdn/contribute/github_best_practices/index.md | 69 +-- files/fr/mdn/contribute/github_cheatsheet/index.md | 98 +-- files/fr/mdn/contribute/help_beginners/index.md | 176 +++--- .../howto/convert_code_samples_to_be_live/index.md | 27 +- .../howto/create_and_edit_pages/index.md | 59 +- files/fr/mdn/contribute/howto/index.md | 6 +- .../write_a_new_entry_in_the_glossary/index.md | 117 ++-- files/fr/mdn/contribute/index.md | 160 +++-- files/fr/mdn/contribute/localize/index.md | 72 +-- .../mdn/contribute/open_source_etiquette/index.md | 186 +++--- files/fr/mdn/contribute/processes/index.md | 8 +- .../fr/mdn/contribute/where_is_everything/index.md | 30 +- .../fr/mdn/guidelines/code_guidelines/css/index.md | 300 ++++----- .../guidelines/code_guidelines/general/index.md | 173 +++--- .../mdn/guidelines/code_guidelines/html/index.md | 205 ++++--- files/fr/mdn/guidelines/code_guidelines/index.md | 62 +- .../guidelines/code_guidelines/javascript/index.md | 605 +++++++++--------- .../mdn/guidelines/code_guidelines/shell/index.md | 31 +- .../guidelines/conventions_definitions/index.md | 203 +++---- .../guidelines/does_this_belong_on_mdn/index.md | 94 ++- files/fr/mdn/guidelines/editorial/index.md | 28 +- files/fr/mdn/guidelines/index.md | 6 +- files/fr/mdn/guidelines/video/index.md | 325 ++++------ .../fr/mdn/guidelines/writing_style_guide/index.md | 110 ++-- files/fr/mdn/index.md | 35 +- files/fr/mdn/structures/index.md | 8 +- files/fr/mdn/structures/live_samples/index.md | 186 +++--- .../macros/commonly-used_macros/index.md | 230 +++---- files/fr/mdn/structures/macros/index.md | 43 +- files/fr/mdn/tools/index.md | 8 +- files/fr/mdn/yari/index.md | 18 +- 38 files changed, 2465 insertions(+), 2659 deletions(-) (limited to 'files/fr/mdn') diff --git a/files/fr/mdn/about/index.md b/files/fr/mdn/about/index.md index a39a1964a8..3f561c9255 100644 --- a/files/fr/mdn/about/index.md +++ b/files/fr/mdn/about/index.md @@ -6,26 +6,26 @@ tags: 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 :

+{{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

+- les standards du Web, tels que [CSS](/fr/docs/CSS), [HTML](/fr/docs/Web/HTML) et [JavaScript](/fr/docs/JavaScript) +- le [développement d’applications web ouvertes](/fr/Apps) +- le [développement d’extensions pour Firefox](/fr/docs/Mozilla/Add-ons) -

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 !

+## Comment aider -

Historique du projet

+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](/fr/docs/MDN/Débuter_sur_MDN) en se basant sur ce qui vous intéresse et combien de temps vous avez à donner ! -

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.

+## Historique du projet -

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 projet _Mozilla Developer Network_ (à l’origine _Mozilla Developer Center_ (MDC) ou encore _Devmo_) a commencé début 2005, lorsque la [fondation Mozilla](https://www.mozilla.org/foundation/) a obtenu une licence d'AOL afin d'utiliser le contenu original de l'ancien site de documentation de Netscape, [DevEdge](http://web.archive.org/web/20040926065921/devedge.netscape.com/). 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. -

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.

+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](/fr/demos/), permettant aux développeurs web de partager et exposer leur code, ainsi que les pages « [Apprendre](/fr/learn) », 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. -

À propos de Mozilla

+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](http://www.xulfr.org/) et de [Geckozone](https:/forums.mozfr.org/) 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. -

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.

+## À 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](https://www.mozilla.org/fr/mission/). diff --git a/files/fr/mdn/at_ten/history_of_mdn/index.md b/files/fr/mdn/at_ten/history_of_mdn/index.md index b127966556..4e5e7b77ac 100644 --- a/files/fr/mdn/at_ten/history_of_mdn/index.md +++ b/files/fr/mdn/at_ten/history_of_mdn/index.md @@ -6,184 +6,182 @@ tags: 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.

+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](https://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

+### Audio - + +``` - +```css hidden + body{margin-top:8px;} +``` +{{ EmbedLiveSample('Audio', 'auto', '50px') }} -

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

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](hoosteeno.jpg) -

Justin Crawford Product Manager, MDN

+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](https://twitter.com/hoosteeno). -

Justin Crawford

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

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.

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

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.

+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 "Sheppy" Shepherd Écrivain technique, MDN -

Eric Shepherd

+![Eric Shepherd](a2sheppy.png) -

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.

+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](https://twitter.com/sheppy). -

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

+## 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 :

+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](https://web.archive.org/web/20020819120942/http://devedge.netscape.com/) : -

Netscape DevEdge

+[![Netscape DevEdge](devedge.png)](https://web.archive.org/web/20020819120942/http://devedge.netscape.com/) -

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.

+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](https://blog.lizardwrangler.com/) put [secourir DevEdge](https://blog.lizardwrangler.com/2005/02/23/devmo-and-devedge-updates/) 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é.

+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

+## 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.

+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

+[![MDC MediaWiki](mediawiki.png)](https://web.archive.org/web/20051226031957/http://developer.mozilla.org/en/docs/Main_Page) -

Florian Scholz Écrivain technique, MDN

+## 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.

+![Florian Scholz](elchi3.jpg) -

DekiWiki Le deuxième moteur wiki

+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](https://twitter.com/floscholz). -

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.

+## DekiWiki Le deuxième moteur wiki -

MDC DekiWiki

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

Ali Spivak Gardienne des supers chats de MDN

+[![MDC DekiWiki](screenshot_2018-07-24_16.06.55.png)](https://web.archive.org/web/20080907231611/http://developer.mozilla.org/en) -

Ali Spivak

+## Ali Spivak Gardienne des supers chats de MDN -

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.

+![Ali Spivak](iyqi3qpv.jpg) -

Kuma Le troisième (et actuel) moteur wiki

+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](https://twitter.com/alispivak). -

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.

+## Kuma Le troisième (et actuel) moteur wiki -

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.

+[Kuma](https://github.com/mozilla/kuma), qui fut une fourche de [Kitsune](https://github.com/mozilla/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](/en-US/docs/MDN/Kuma/Introduction_to_KumaScript) et qui est basé sur Node.js. -

MDN KUMA

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

David Walsh Développeur web, MDN

+[![MDN KUMA](kuma.png)](https://web.archive.org/web/20121003233220/https://developer.mozilla.org/en-US/) -

David Walsh

+## David Walsh Développeur web, MDN -

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.

+![David Walsh](darkwing.png) -

Refondre MDN Kuma, rafraîchi

+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](https://twitter.com/davidwalshblog) sur Twitter. -

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 +## Refondre MDN Kuma, rafraîchi -

Janet Swisher Community Manager, MDN

+La refonte de MDN fut un gros projet. [Sean Martell](https://twitter.com/mart3ll) 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](https://twitter.com/davidwalshblog/) qui fut le principal acteur de cette refonte et qui offrit à MDN le style qu'il méritait. -

Janet Swisher

+![Waffle flag](waffle-flag.jpg) -

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.

+## Janet Swisher Community Manager, MDN -

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

+![Janet Swisher](jmswisher.jpg) -

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.

+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](https://twitter.com/jmswisher). -

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.

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

Luke Crouch développeur web, MDN

+En 2010, notamment [lorsque les membres de la communauté et les écrivains techniques se sont recontrés à Paris](https://hacks.mozilla.org/2010/10/web-standards-doc-sprint-finis/), 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. -

Luke Crouch

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

+## Luke Crouch développeur web, MDN -

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

+![Luke Crouch](groovecoder.png) -

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.

+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](https://twitter.com/groovecoder). -

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

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

Julien

+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](/en-US/docs/MDN/Contribute/Localize). 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 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.

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

Jean-Yves Perrier Écrivain technique, MDN

+![Julien](ensemble.png) -

Jean-Yves Perrier

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

+## Jean-Yves Perrier Écrivain technique, MDN +![Jean-Yves Perrier](teoli2003.png) -

« Learning Area » ou Apprendre le Web

+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](https://twitter.com/Teoli2003). -

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.

+## « Learning Area » ou Apprendre le Web -

Jérémie Patonnier Écrivain technique, MDN

+La [Learning Area](https://developer.mozilla.org/en-US/Learn) 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

+## Jérémie Patonnier Écrivain technique, MDN -

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.

+![Jérémie Patonnier](jeremiepat.jpg) -

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

+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](https://twitter.com/JeremiePat). -

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.

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

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.

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

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

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.

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

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

+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 +- Les Orchard +- John Karahalis +- David Walsh +- Jannis Leidel +- Stephanie Hobson +- James Bennett +- Isac Lagerblad +- Piotrek Koszuliński +- Craig Cook +- Rob Hudson +- John Whitlock +- ...Et bien d'autres [contributeurs à Kuma.](https://github.com/mozilla/kuma/graphs/contributors) - + -The Berlin Office +- Chris Mills +- Will Bamberg +- David Bruant +- Thierry Régagnon +- etherthank +- Saurabh Nair +- Deb Richardson +- Sebastian Zartner +- Tooru Fujisawa +- Karen Scarfone +- Niklas Barning +- ... + Et des centaines de contributeurs au wiki. +![The Berlin Office](11073502_781006205281080_8135317797319228200_o-600x400.jpg) diff --git a/files/fr/mdn/at_ten/index.md b/files/fr/mdn/at_ten/index.md index 08e46f4829..79e4969746 100644 --- a/files/fr/mdn/at_ten/index.md +++ b/files/fr/mdn/at_ten/index.md @@ -7,30 +7,26 @@ tags: translation_of: MDN_at_ten original_slug: MDN_a_dix_ans --- -
-

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

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

L'histoire de MDN

+## 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.

+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

+[En savoir plus](/fr/docs/MDN_a_dix_ans/Histoire_MDN) +## Contribuer à MDN -

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

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](/fr/docs/MDN_a_dix_ans/Contribuer_à_MDN) -

En savoir plus

+> Quand je souhaite comprendre « pourquoi » plutôt que « comment », j'utilise MDN. -
Quand je souhaite comprendre « pourquoi » plutôt que « comment », j'utilise MDN.
-— Christian Heilmann +— [Christian Heilmann](https://twitter.com/codepo8/status/621009648875868160) - +## Subnav -
    -
  1. MDN a 10 ans
  2. -
  3. L'histoire de MDN
  4. -
  5. Contribuer à MDN
  6. -
+1. [MDN a 10 ans](/fr/docs/MDN_a_dix_ans/) +2. [L'histoire de MDN](/fr/docs/MDN_a_dix_ans/Histoire_MDN) +3. [Contribuer à MDN](/en-US/docs/MDN_at_ten/Contributing_to_MDN) diff --git a/files/fr/mdn/contribute/documentation_priorities/index.md b/files/fr/mdn/contribute/documentation_priorities/index.md index 9f56f5fcaa..1dee08a75c 100644 --- a/files/fr/mdn/contribute/documentation_priorities/index.md +++ b/files/fr/mdn/contribute/documentation_priorities/index.md @@ -9,214 +9,179 @@ tags: - 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)

- - +{{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 : + +- Aider à appliquer des mesures de priorité aux bogues de contenu pendant notre processus de triage, ce qui aide les contributeurs à prendre une décision sur les bogues sur lesquels travailler en découvrant ceux qui sont les plus importants pour le moment. +- Aider les contributeurs qui souhaitent travailler sur un sujet spécifique (plutôt que sur un bogue particulier) à décider du sujet où il serait le plus utile de consacrer du temps (par exemple, pour les personnes qui aiment exécuter des scripts de nettoyage automatique sur MDN). + +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. + +- [Accessibilité](/fr/docs/Web/Accessibility) (104) +- [CSS : Feuilles de style en cascade](/fr/docs/Web/CSS) (933) +- [Événements](/fr/docs/Web/Events) (4) +- [HTML : HyperText Markup Language](/fr/docs/Web/HTML) (239) +- [HTTP](/fr/docs/Web/HTTP) (292) +- [JavaScript](/fr/docs/Web/JavaScript) (921) +- [Apprendre le développement web](/fr/docs/Learn) (355) +- [Médias sur le Web](/fr/docs/Web/Media) (17) +- [Performance](/fr/docs/Web/Performance) (16) +- [Vie privée](/fr/docs/Web/Privacy) (1) +- [Applications web progressives](/fr/docs/Web/Progressive_web_apps) (16) +- [Sécurité](/fr/docs/Web/Security) (27) +- [Référence des API Web](/fr/docs/Web/API) : Les interfaces des groupes suivants sont de niveau 1 (voir la section [API Web de niveau 1](#tier_1_webapis) ci-dessous pour un éventail plus large de ce que cela inclut (1189) : + + - Canvas API (112) + - Clipboard API (13) + - DOM (439) + - DOM Events (22) + - Fetch API (47) + - File API (48) + - HTML DOM (371) + - URL API (43) + - Web Storage API (8) + - WebSockets API (28) + - XMLHttpRequest (58) + +- [Manifestes des applications web](/fr/docs/Web/Manifest) (19) +- [WebAssembly](/fr/docs/WebAssembly) (12) +- [Composants web](/fr/docs/Web/Web_Components) (5) + +**Total des pages pour le niveau 1 : 4150** + +## Niveau 2 + +Le contenu de niveau 2 est moins couramment utilisé, mais néanmoins utile. + +- [CSS Houdini](/fr/docs/Web/Houdini) (1) +- [Développement de jeux vidéo](/fr/docs/Games) (73) +- [Guides pour les développeurs du Web](/fr/docs/Web/Guide) (56) +- [MathML](/fr/docs/Web/MathML) (38) +- [Le projet MDN](/fr/docs/MDN) (82). C'est important, mais les corrections seront principalement traitées par l'équipe principale du MDN). +- [SVG](/fr/docs/Web/SVG) (382) +- [Le glossaire](/fr/docs/Glossary) (534) +- [Référence des API Web](/fr/docs/Web/API) pour celles qui ne figurent pas parmi celles de niveau 1. (4701) +- [WebExtensions](/fr/docs/Mozilla/Add-ons/WebExtensions) (635). Pas vraiment un sujet en lien direct avec la plateforme web, mais quand même important. + +**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 . + +### Canvas API (112) + +- [`CanvasGradient`](/fr/docs/Web/API/CanvasGradient) (2) +- [`CanvasImageSource`](/fr/docs/Web/API/CanvasImageSource) (1) +- [`CanvasPattern`](/fr/docs/Web/API/CanvasPattern) (2) +- [`CanvasRenderingContext2D`](/fr/docs/Web/API/CanvasRenderingContext2D) (71) +- [`ImageBitmap`](/fr/docs/Web/API/ImageBitmap) (4) +- [`ImageBitmapRenderingContext`](/fr/docs/Web/API/ImageBitmapRenderingContext) (2) +- [`ImageData`](/fr/docs/Web/API/ImageData) (5) +- [`OffscreenCanvas`](/fr/docs/Web/API/OffscreenCanvas) (8) +- [`Path2D`](/fr/docs/Web/API/Path2D) (3) +- [`RenderingContext`](/fr/docs/Web/API/RenderingContext) (1) +- [`TextMetrics`](/fr/docs/Web/API/TextMetrics) (13) + +### Clipboard API (13) + +- [`Clipboard`](/fr/docs/Web/API/Clipboard) (5) +- [`ClipboardEvent`](/fr/docs/Web/API/ClipboardEvent) (3) +- [`ClipboardItem`](/fr/docs/Web/API/ClipboardItem) (5) + +### 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. + +- [`AbortController`](/fr/docs/Web/API/AbortController) (4) +- [`ChildNode`](/fr/docs/Web/API/ChildNode) (5) +- [`CustomEvent`](/fr/docs/Web/API/CustomEvent) (4) +- [`Document`](/fr/docs/Web/API/Document) (164) +- [`DOMParser`](/fr/docs/Web/API/DOMParser) (2) +- [`DOMString`](/fr/docs/Web/API/DOMString) (2) +- [`Element`](/fr/docs/Web/API/Element) (176) +- [`Event`](/fr/docs/Web/API/Event) (24) +- [`EventTarget`](/fr/docs/Web/API/EventTarget) (5) +- [`HTMLCollection`](/fr/docs/Web/API/HTMLCollection) (4) +- [`MutationObserver`](/fr/docs/Web/API/MutationObserver) (5) +- [`Node`](/fr/docs/Web/API/Node) (36) +- [`NodeList`](/fr/docs/Web/API/NodeList) (7) +- [`USVString`](/fr/docs/Web/API/USVString) (1) + +### 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. + +- [`EventListener`](/fr/docs/Web/API/EventListener) (2) +- [`KeyboardEvent`](/fr/docs/Web/API/KeyboardEvent) (20) + +### Fetch API (47) + +- [`Body`](/fr/docs/Web/API/Body) (8) +- [`Headers`](/fr/docs/Web/API/Headers) (11) +- [`Request`](/fr/docs/Web/API/Request) (15) +- [`Response`](/fr/docs/Web/API/Response) (13) + +### File API (48) + +- [`Blob`](/fr/docs/Web/API/Blob) (8) +- [`File`](/fr/docs/Web/API/File) (15) +- [`FileList`](/fr/docs/Web/API/FileList) (1) +- [`FileReader`](/fr/docs/Web/API/FileReader) (19) +- [`FileReaderSync`](/fr/docs/Web/API/FileReaderSync) (5) + +### 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. + +- [`History`](/fr/docs/Web/API/History) (9) +- [`HTMLAudioElement`](/fr/docs/Web/API/HTMLAudioElement) (4) +- [`HTMLCanvasElement`](/fr/docs/Web/API/HTMLCanvasElement) (14) +- [`HTMLElement`](/fr/docs/Web/API/HTMLElement) (45) +- [`HTMLFormElement`](/fr/docs/Web/API/HTMLFormElement) (17) +- [`HTMLInputElement`](/fr/docs/Web/API/HTMLInputElement) (17) +- [`HTMLTextAreaElement`](/fr/docs/Web/API/HTMLTextAreaElement) (2) +- [`Location`](/fr/docs/Web/API/Location) (17) +- [`Navigator`](/fr/docs/Web/API/Navigator) (45) +- [`NavigatorLanguage`](/fr/docs/Web/API/NavigatorLanguage) (3) +- [`NavigatorOnLine`](/fr/docs/Web/API/NavigatorOnLine) (3) +- [`Window`](/fr/docs/Web/API/Window) (182) +- [`WindowEventHandlers`](/fr/docs/Web/API/WindowEventHandlers) (13) + +### URL API (43) + +- [`URL`](/fr/docs/Web/API/URL) (18) +- [`URLSearchParams`](/fr/docs/Web/API/URLSearchParams) (14) +- [`URLUtilsReadOnly`](/fr/docs/Web/API/URLUtilsReadOnly) (11) + +### Web Storage API (8) + +- [`Storage`](/fr/docs/Web/API/Storage) (7) +- [`StorageEvent`](/fr/docs/Web/API/StorageEvent) (1) + +### WebSockets API (28) + +- [`CloseEvent`](/fr/docs/Web/API/CloseEvent) (3) +- [`MessageEvent`](/fr/docs/Web/API/MessageEvent) (7) +- [`WebSocket`](/fr/docs/Web/API/WebSocket) (18) + +### XMLHttpRequest (58) + +- [`FormData`](/fr/docs/Web/API/FormData) (12) +- [`XMLHttpRequest`](/fr/docs/Web/API/XMLHttpRequest) (40) +- [`XMLHttpRequestEventTarget`](/fr/docs/Web/API/XMLHttpRequestEventTarget) (6) diff --git a/files/fr/mdn/contribute/feedback/index.md b/files/fr/mdn/contribute/feedback/index.md index 29c900a3c5..014ab9f8e7 100644 --- a/files/fr/mdn/contribute/feedback/index.md +++ b/files/fr/mdn/contribute/feedback/index.md @@ -8,60 +8,54 @@ tags: - MDN Meta translation_of: MDN/Contribute/Feedback --- -
{{MDNSidebar}}
+{{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.

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

+Il y existe plusieurs façons pour porter votre voix, cet article vous les explique. -

Mettre à jour la documentation

+## 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.

+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](https://github.com/mdn/content/#making-contributions). -

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

+Si vous souhaitez savoir comment contribuer aux traductions en français, vous pouvez également lire [ce billet](https://tech.mozfr.org/post/2021/03/16/MDN-sur-GitHub-comment-contribuer). -

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.

+Les sources de la documentation ici sont [stockées dans GitHub](https://github.com/mdn/translated-content/), 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 :

+Pour plus d'information sur comment contribuer à la documentation : - +- [Débuter sur MDN](/fr/docs/MDN/Contribute/Getting_started) +- [Contribuer à MDN](/fr/docs/MDN/Contribute) -

Rejoignez la conversation

+## 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.

+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

+### Discussions en direct - chats -

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

+Nous utilisons [Matrix](https://wiki.mozilla.org/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).
-
+- [MDN Web Docs](https://chat.mozilla.org/#/room/#mdn:mozilla.org) + - : 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](https://chat.mozilla.org/#/room/#l10n-fr:mozilla.org) + - : 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)

+### 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.

+Les discussions plus importantes et qui ne nécessitent pas d'être connecté à tout moment se déroulent sur [le forum Discourse](https://discourse.mozilla-community.org/c/mdn). Vous pouvez envoyer des messages sur ce forum par e-mail en utilisant l'adresse [mdn@mozilla-community.org](mailto://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

+## Signaler un problème -

Problèmes dans la documentation

+### 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 :

+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](https://github.com/mdn/translated-content/issues/new "Signaler un problème de contenu de la documentation."). Vous pouvez utiliser ce formulaire pour tout problème avec la documentation, pas exemple : - +- une simple correction +- une demande de contenu entièrement nouveau +- signaler les contenus inappropriés (y compris le spam et les traductions mal placées) -

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

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

Problèmes sur le site

+### 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.

+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](hhttps://github.com/mdn/yari/issues). diff --git a/files/fr/mdn/contribute/getting_started/index.md b/files/fr/mdn/contribute/getting_started/index.md index 563a36e2d7..9ecf83d0cc 100644 --- a/files/fr/mdn/contribute/getting_started/index.md +++ b/files/fr/mdn/contribute/getting_started/index.md @@ -10,50 +10,45 @@ tags: - New Contributors translation_of: MDN/Contribute/Getting_started --- -
{{MDNSidebar}}
+{{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.

+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 !

+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

+## 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).

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

+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

+### Étape 1 : Créer un compte GitHub -

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

+Pour commencer vos contributions à MDN, vous devez [créer un compte GitHub](https://github.com/mdn/content/#setup). +### Étape 2 : Choisir une tâche à accomplir -

É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](/fr/docs/MDN/Contribute), et décidez de celle qui vous attire le plus. Vous pouvez choisir la tâche qui vous convient et commencer à contribuer. -

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 -

É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 ! -

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 -

É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 : -

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 :

+- Si vous voulez nous parler de manière synchrone et poser des questions sur MDN lui-même, rejoignez la discussion sur le salon de discussion [Localisation / traduction en français](https://chat.mozilla.org/#/room/#l10n-fr:mozilla.org) sur [Matrix](https://wiki.mozilla.org/Matrix). +- Vous pouvez également nous envoyer un e-mail à . +- Si vous apprenez le développement web et êtes bloqué sur un problème de codage, nous avons des [forums actifs](https://discourse.mozilla.org/c/mdn/learn/250) où vous pouvez poser des questions et obtenir de l'aide. -
    -
  • Si vous voulez nous parler de manière synchrone et poser des questions sur MDN lui-même, rejoignez la discussion sur le salon de discussion Localisation / traduction en français sur Matrix.
  • -
  • Vous pouvez également nous envoyer un e-mail à mdn-admins@mozilla.org.
  • -
  • Si vous apprenez le développement web et êtes bloqué sur un problème de codage, nous avons des forums actifs où vous pouvez poser des questions et obtenir de l'aide.
  • -
+Ne vous souciez pas de le faire parfaitement ; d'autres contributeurs MDN sont là pour aider à corriger les erreurs qui se glissent. -

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 -

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

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 :

- - +- Technologies web : Si vous êtes novice en HTML, CSS, JavaScript, etc., consultez nos tutoriels pour [Apprendre le développement web](/fr/docs/Learn). +- Open source : Si vous n'avez jamais contribué à un projet open source, lisez [L'étiquette de base des projets open source](/fr/docs/MDN/Contribuer/Open_source_etiquette). +- Git et GitHub : Si vous n'êtes pas familier avec ces outils, [GitHub pour les grands débutants](/fr/docs/MDN/Contribute/GitHub_beginners) vous permettra de démarrer. Vous pouvez également consulter [ce billet sur les contributions à MDN avec Git.](https://tech.mozfr.org/post/2021/03/16/MDN-sur-GitHub-comment-contribuer) +- Les structures de dépôt de MDN : Si vous ne savez pas quels dépôts modifier pour apporter des modifications aux différentes parties du contenu de MDN, [Où se trouve tout sur MDN ?](/fr/docs/MDN/Contribute/Where_is_everything) vous orientera vers les bons endroits. diff --git a/files/fr/mdn/contribute/github_beginners/index.md b/files/fr/mdn/contribute/github_beginners/index.md index 96dff3ffa4..28f01d1226 100644 --- a/files/fr/mdn/contribute/github_beginners/index.md +++ b/files/fr/mdn/contribute/github_beginners/index.md @@ -9,430 +9,420 @@ tags: - Beginners translation_of: MDN/Contribute/GitHub_beginners --- -

{{MDNSidebar}}

+{{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.

+[Git](https://git-scm.com/) et [GitHub](https://github.com/) 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.

+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](/fr/docs/MDN/Contribute/GitHub_cheatsheet) disponible, avec juste les commandes et aucune des longues explications. -

Concepts essentiels

+## Concepts essentiels -

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

+Voici les concepts essentiels que vous devez connaître pour tirer le meilleur parti de Git et de GitHub. -
    -
  • Git est un outil de système de contrôle de version - une classe d'outils essentielle dans tout flux de développement. Il permet à un groupe de développeurs de travailler sur la même base de code sans se gêner mutuellement, stocke la base de code en toute sécurité dans un emplacement distant, permet aux développeurs de revenir à des états antérieurs si nécessaire, et plus encore.
  • -
  • GitHub est une application web qui fournit des outils utiles au-dessus de Git pour travailler avec des bases de code stockées, ainsi qu'un espace serveur pour stocker les bases de code. Elle fait des choses similaires à d'autres applications dans cet espace, comme GitLab ou Bitbucket.
  • -
  • Chaque base de code est stockée dans un conteneur appelé repository, ou repo. En français « dépôt ».
  • -
  • Apporter une modification à un référentiel implique au minimum : -
      -
    • Créer votre propre copie de ce dépôt (appelé un fork ou « bifurcation »).
    • -
    • Créer une version différente du code dans votre bifurcation du dépôt (appelée une branch ou « branche ») et ajouter vos modifications à cette version alternative.
    • -
    • Proposer d'effectuer cette modification dans la copie originale du dépôt via une pull request ou « demande de triage ». Vous apprendrez toutes ces étapes dans ce guide.
    • -
    -
  • -
+- Git est un outil de _système de contrôle de version_ - une classe d'outils essentielle dans tout flux de développement. Il permet à un groupe de développeurs de travailler sur la même base de code sans se gêner mutuellement, stocke la base de code en toute sécurité dans un emplacement distant, permet aux développeurs de revenir à des états antérieurs si nécessaire, et plus encore. +- GitHub est une application web qui fournit des outils utiles au-dessus de Git pour travailler avec des bases de code stockées, ainsi qu'un espace serveur pour stocker les bases de code. Elle fait des choses similaires à d'autres applications dans cet espace, comme [GitLab](https://about.gitlab.com/) ou [Bitbucket](https://bitbucket.org/). +- Chaque base de code est stockée dans un conteneur appelé _repository_, ou _repo_. En français « dépôt ». +- Apporter une modification à un référentiel implique au minimum : -

Hypothèses formulées par cet article

+ - Créer votre propre copie de ce dépôt (appelé un _fork_ ou « bifurcation »). + - Créer une version différente du code dans votre bifurcation du dépôt (appelée une _branch_ ou « branche ») et ajouter vos modifications à cette version alternative. + - Proposer d'effectuer cette modification dans la copie originale du dépôt via une _pull request_ ou « demande de triage ». Vous apprendrez toutes ces étapes dans ce guide. -

Cet article part du principe que :

+## Hypothèses formulées par cet article -
    -
  • Vous êtes déjà à l'aise avec l'utilisation de la ligne de commande/du terminal. Si la ligne de commande vous est inconnue, lisez notre Cours accéléré sur les lignes de commande.
  • -
  • Vous travaillez sur un système qui comprend les commandes de ligne de commande standard de style Unix. macOS/Linux disposent de cette fonctionnalité dès le départ ; Windows n'est pas tout à fait aussi simple à cet égard, mais il existe des applications utiles qui émulent cette fonctionnalité sous Windows, comme Git Bash.
  • -
  • Vous utiliserez la ligne de commande pour interagir avec Git/GitHub. Il existe un certain nombre d'outils GUI pour Git et GitHub, mais ils ne fonctionneront pas avec ce guide.
  • -
+Cet article part du principe que : -

Configuration initiale

+- Vous êtes déjà à l'aise avec l'utilisation de la ligne de commande/du terminal. Si la ligne de commande vous est inconnue, lisez notre [Cours accéléré sur les lignes de commande](/fr/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line). +- Vous travaillez sur un système qui comprend les commandes de ligne de commande standard de style Unix. macOS/Linux disposent de cette fonctionnalité dès le départ ; [Windows n'est pas tout à fait aussi simple](/fr/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line#windows) à cet égard, mais il existe des applications utiles qui émulent cette fonctionnalité sous Windows, comme Git Bash. +- Vous utiliserez la ligne de commande pour interagir avec Git/GitHub. Il existe un certain nombre d'outils GUI pour Git et GitHub, mais ils ne fonctionneront pas avec ce guide. -

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

+## Configuration initiale -
    -
  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. -
  3. 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. -
    3. Une fois que vous avez installé Node.js, installez yarn en exécutant npm install --global yarn.
    4. -
    -
  4. -
  5. 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é.
  6. -
  7. 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.
  8. -
+Avant de commencer à travailler sur un dépôt particulier, suivez ces étapes : -

Configuration de l'authentification SSH sur GitHub

+1. Installez Git sur votre ordinateur. Allez sur la [page de téléchargement de Git](https://git-scm.com/downloads), 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](https://gitforwindows.org/), qui inclut Gitbash. +2. Pendant que vous y êtes, installez les autres dépendances requises pour travailler localement avec MDN - [Node.js](https://nodejs.org/en/download/) et [yarn](https://classic.yarnpkg.com/en/docs/install). -

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

+ 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. Une fois que vous avez installé Node.js, installez yarn en exécutant `npm install --global yarn`. -

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.

+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. [Créez un compte GitHub](https://github.com/join) si vous n'en avez pas déjà un. Vous aurez besoin d'un compte pour contribuer aux dépôts de MDN. -

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

+### Configuration de l'authentification SSH sur GitHub -

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

+À 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](https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-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

-
+ +> **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 `/content` par `/translated-content` +> +> Vous pouvez retrouver des explications de ceci sur notre article [Comment contribuer sur GitHub au MDN](https://tech.mozfr.org/post/2021/03/16/MDN-sur-GitHub-comment-contribuer) + -

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.

+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](/fr/docs/MDN/Contribute/Where_is_everything)), 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 : + +- « Forking » (ou Bifurquer) signifie créer votre propre copie d'un dépôt sur GitHub. +- « Cloning » (ou Cloner) consiste à faire une copie locale d'un dépôt sur lequel vous pouvez travailler (c'est-à-dire sur votre disque dur local). + +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 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é.](fork-button.png) + +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 est disponible l'adresse . + +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//content`). +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.](code-popup.png) + +3. Si vous avez configuré l'authentification SSH comme indiqué ci-dessus, cliquez sur l'onglet "SSH" et copiez l'URL `git@github.com:/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//content.git`. +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. + + ```bash + cd git + ``` + +5. Clonez votre bifurcation en entrant une commande de la forme suivante : + + ```bash + git clone url-que-vous-avez-copié + ``` + + Ainsi, par exemple, ma commande de clonage ressemblait à ceci : + + ```bash + git clone git@github.com:chrisdavidmills/content.git + ``` + +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 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 : + +```bash +git remote add remote-name repo-you-want-to-point-to +``` + +- `remote-name` est le nom que vous décidez, qui est utilisé pour se référer à suivi distant plus tard. Il est bon de s'en tenir à un nom cohérent pour bien distinguer les différents dépôts qui ont le même but, ainsi le même nom de suivi fera la même chose partout, et vous êtes moins susceptibles d'être confus. Ainsi, par exemple, la version principale du dépôt à partir duquel vous avez bifurqué votre version est souvent appelée « dépôt ascendant », c'est pourquoi les gens utilisent souvent « upstream » comme nom de l'emplacement ascendant distant. J'appelle généralement mes suivi ascendant "mozilla", pour signifier qu'ils pointent vers la copie principale du dépôt de Mozilla. +- `repo-you-want-to-point-to` est l'URL SSH (ou HTTPS) du dépôt vers lequel vous voulez pointer, récupérée de la même manière que lorsque nous avons cloné notre bifurcation plus tôt. + +Donc, pour ajouter votre suivi : + +1. Allez sur la page github.com de la version principale du dépôt ( dans cet exemple) et récupérez l'URL SSH ou HTTPS selon le cas, dans la fenêtre contextuelle « Code ». +2. Dans votre console de commande, utilisez `cd` pour aller dans votre répertoire de contenu : + + ```bash + cd content + ``` + +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 : + + ```bash + 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" : + + ```bash + git remote add mozilla git@github.com:mdn/content.git + ``` + +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 -

Bifurcation et clonage

+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 Bifurcation et le Clonage sont deux termes que vous rencontrerez souvent dans le monde de Git :

+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. -
    -
  • « Forking » (ou Bifurquer) signifie créer votre propre copie d'un dépôt sur GitHub.
  • -
  • « Cloning » (ou Cloner) consiste à faire une copie locale d'un dépôt sur lequel vous pouvez travailler (c'est-à-dire sur votre disque dur local).
  • -
+Assurez-vous d'exécuter la commande suivante pour passer à la branche principale avant de faire quoi que ce soit d'autre : -

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.

+```bash +git switch main +``` -

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 :

+> **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](https://github.blog/2019-08-16-highlights-from-git-2-23/#experimental-alternatives-for-git-checkout) fournit un bon résumé. -
    -
  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. -
  3. -

    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.

    -
  4. -
+### Mettre à jour votre branche principale -

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

    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.

    -
  4. -
  5. -

    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.

    -
  6. -
  7. -

    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
    -
  8. -
  9. -

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

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
- -
    -
  • remote-name est le nom que vous décidez, qui est utilisé pour se référer à suivi distant plus tard. Il est bon de s'en tenir à un nom cohérent pour bien distinguer les différents dépôts qui ont le même but, ainsi le même nom de suivi fera la même chose partout, et vous êtes moins susceptibles d'être confus. Ainsi, par exemple, la version principale du dépôt à partir duquel vous avez bifurqué votre version est souvent appelée « dépôt ascendant », c'est pourquoi les gens utilisent souvent « upstream » comme nom de l'emplacement ascendant distant. J'appelle généralement mes suivi ascendant "mozilla", pour signifier qu'ils pointent vers la copie principale du dépôt de Mozilla.
  • -
  • repo-you-want-to-point-to est l'URL SSH (ou HTTPS) du dépôt vers lequel vous voulez pointer, récupérée de la même manière que lorsque nous avons cloné notre bifurcation plus tôt.
  • -
- -

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

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

    -
    cd content
    -
  4. -
  5. -

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

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.

+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 ! -

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.

+Pour mettre à jour votre dépôt : -

Passer à la branche principale

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

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.

+ ```bash + git fetch remote-name + ``` -

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.

+ Par exemple : -

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

+ ```bash + git fetch mozilla + ``` -
git switch main
+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 : -
-

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

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

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

    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
    -
  4. -
  5. -

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

    -
    git push
    -
  6. -
- -

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 :

+ Par exemple : -
    -
  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. -
  3. -

    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

    -
  4. -
  5. -

    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

    -
  6. -
  7. -

    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

    -
  8. -
+ ```bash + git rebase mozilla/main + ``` -

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 :

+3. Enfin, poussez ces changements vers la version distante de votre bifircation en utilisant : -
    -
  • Assurez-vous de toujours mettre à jour votre branche principale pour qu'elle soit synchronisée avec la branche principale de mozilla, comme indiqué dans la section précédente, avant de créer une nouvelle branche.
  • -
  • Assurez-vous de toujours créer votre nouvelle branche en vous basant sur main, et non sur une autre branche, en vérifiant que le bouton de la branche affiche "main" avant de lancer le processus. Si vous ne le faites pas, votre nouvelle branche risque d'être vraiment obsolète, ce qui créera des problèmes de contenu.
  • -
- -

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.

+ ```bash + git push + ``` -

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) :

+Vous saurez si vos mises à jour ont fonctionné correctement en regardant la page github.com de votre fork (c-à-d. que la mienne est ). 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](#troubleshooting). -
    -
  1. Tirez les changements distants vers votre clone local en exécutant la commande git pull.
  2. -
  3. Vous devriez obtenir un message du type * [new branch] test-branch -> origin/test-branch.
  4. -
  5. 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.
  6. -
+### Créez une nouvelle branche pour y faire vos modifications -

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

+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. -
Branch 'test-branch' set up to track remote branch 'test-branch' from 'origin'.
-Switched to a new branch 'test-branch'
+Pour créer une nouvelle branche : -

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 :

+1. Allez sur la page de votre bifurcation sur github.com (la mienne est à l'adresse ) et trouvez le bouton de branche en haut à gauche de la liste des fichiers, qui devrait indiquer « main » : -
On branch test-branch
-Your branch is up to date with 'origin/test-branch'.
+    ![Bouton intitulé main](branch-button.png)
 
-nothing to commit, working tree clean
+2. Cliquez dessus, et vous verrez apparaître une liste de branches et un champ de texte indiquant « Find or create a branch… » : -

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

+ ![menu montrant une liste de noms de branches avec une zone de texte étiquetée trouver ou créer une branche](branch-menu.png) -

Ajouter, valider et pousser les changements

+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' » : -

À 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. -
  3. -

    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")
    -
  4. -
  5. -

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

    -
    -
  6. -
  7. -

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

    -
    On branch test-branch
    +    ![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](new-branch.png)
    +
    +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](branch-button-new-branch.png)
    +
    +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 :
    +
    +- Assurez-vous de toujours mettre à jour votre branche principale pour qu'elle soit synchronisée avec la branche principale de mozilla, comme indiqué dans la section précédente, avant de créer une nouvelle branche.
    +- Assurez-vous de toujours créer votre nouvelle branche en vous basant sur main, et non sur une autre branche, en vérifiant que le bouton de la branche affiche "main" avant de lancer le processus. Si vous ne le faites pas, votre nouvelle branche risque d'être vraiment obsolète, ce qui créera des problèmes de contenu.
    +
    +### 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.  Vous devriez obtenir un message du type `* [new branch] test-branch -> origin/test-branch`.
    +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`.
    +
    +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'.
     
    -    Changes to be committed:
    -      (use "git restore --staged <file>..." to unstage)
    -        modified:   README.md
    -
  8. -
  9. -

    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.

    -
  10. -
  11. -

    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
    +
    +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](https://github.com/mdn/translated-content/issues/), ou lisez [Contribuer à MDN](/fr/docs/MDN/Contribute) 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.  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 ..." to update what will be committed)
    +              (use "git restore ..." to discard changes in working directory)
    +                modified:   README.md
    +
    +            no changes added to commit (use "git add" and/or "git commit -a")
    +
    +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 :
    +
    +    ```bash
    +    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.  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 ..." to unstage)
    +                modified:   README.md
    +
    +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 ») :
    +
    +    ```bash
    +    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.  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
    +
    +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.
     
    -    nothing to commit, working tree clean
    -
  12. -
+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. -

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.

+ ![bannière avec le texte test-branch had recent pushes, et un bouton intitulé compare and pull request](compare-and-pull-request.png) -

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 :

+ Appuyez sur ce bouton, et vous devriez obtenir un nouvel écran qui s'affiche comme suit : -
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
+ ![un formulaire de demande de triage ouvert, qui comprend des champs de texte pour le titre et la description](open-pull-request.png) -

Création d'une demande de triage

+ > **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. -

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

+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. 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](https://github.com/mdn/content/pulls) » du dépôt, où elle sera examinée par nos équipes de révision et, si possible, fusionnée dans le code principal. -
    -
  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.

    + 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). -

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

    +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**. -

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

    +## Dépannage -

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

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

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

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

    -
  4. -
  5. -

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

    -
  6. -
  7. -

    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.

    -
  8. -
+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. -

Dépannage

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

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.

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

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.

+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 : -

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.

+```bash +git restore file-path +``` -

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

+### Suppression d'un fichier de la liste de commit -

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 :

+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 file-path
+```bash +git restore --staged file-path +``` -

Suppression d'un fichier de la liste de commit

+### Annuler un 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 :

+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 restore --staged file-path
+```bash +git reset HEAD~1 +``` -

Annuler un commit

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

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 :

+### Inverser un commit qui a été poussé vers la bifurcation distante -
git reset HEAD~1
+À 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. -

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.

+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 : -

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

+ ```bash + git revert HEAD + ``` -

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

+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. Maintenant, il faut juste le pousser : -
    -
  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. -
  3. -

    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.

    -
  4. -
  5. -

    Maintenant, il faut juste le pousser :

    -
    git push
    -
  6. -
+ ```bash + git push + ``` -

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.

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

-
+> **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 ?

+### 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.

+Si vous pensez que ce guide de dépannage devrait contenir plus d'informations, veuillez [créer un ticket](https://github.com/mdn/translated-content/issues/new) pour suggérer ce que vous pensez que nous devrions inclure. -

Voir aussi

+## Voir aussi - +- [Apprendre le développement web > Git et GitHub](/fr/docs/Learn/Tools_and_testing/GitHub) +- [Dangit, Git](https://dangitgit.com/en) — autres techniques de dépannage utiles +- [45 Questions sur GitHub : à faire et à ne pas faire](https://hackernoon.com/45-github-issues-dos-and-donts-dfec9ab4b612) +- [Outils CLI GitHub](https://cli.github.com/) — une fois que vous avez l'habitude d'utiliser les commandes de l'interface CLI de GitHub pour contrôler vos dépôts, vous pouvez envisager d'installer l'outil CLI gh de GitHub, qui fournit des commandes pour accélérer un certain nombre des processus mentionnés ci-dessus. diff --git a/files/fr/mdn/contribute/github_best_practices/index.md b/files/fr/mdn/contribute/github_best_practices/index.md index 146496aba9..cdb4e51825 100644 --- a/files/fr/mdn/contribute/github_best_practices/index.md +++ b/files/fr/mdn/contribute/github_best_practices/index.md @@ -8,42 +8,33 @@ tags: - 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. -
      3. Si c'était il y a moins d'une semaine, soyez patient et donnez-leur une chance d'y travailler.
      4. -
      -
    • -
    -
  2. -
  3. 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.
  4. -
- -

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. -
  3. Une fois que vous pensez avoir résolu une issue, demandez une revue dans les commentaires.
  4. -
  5. 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.
  6. -
  7. 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.
  8. -
+{{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. Si c'était il y a moins d'une semaine, soyez patient et donnez-leur une chance d'y travailler. + +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. + +## 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](https://chat.mozilla.org/#/room/#l10n-fr:mozilla.org) sur [Matrix](https://wiki.mozilla.org/Matrix). + +2. Une fois que vous pensez avoir résolu une _issue_, demandez une revue dans les commentaires. +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. 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. diff --git a/files/fr/mdn/contribute/github_cheatsheet/index.md b/files/fr/mdn/contribute/github_cheatsheet/index.md index 1dddbb8be7..76af916183 100644 --- a/files/fr/mdn/contribute/github_cheatsheet/index.md +++ b/files/fr/mdn/contribute/github_cheatsheet/index.md @@ -11,72 +11,94 @@ tags: - Commands translation_of: MDN/Contribute/GitHub_cheatsheet --- -

{{MDNSidebar}}

+{{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.

+Cet article fournit une référence rapide aux commandes essentielles dont vous aurez besoin lorsque vous utiliserez [Git](https://git-scm.com/) et [GitHub](https://github.com/) 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](/fr/docs/MDN/Contribute/GitHub_beginners) vous enseigne les bases. -

Cloner

+## Cloner -
git clone url-du-depot
+```bash +git clone url-du-depot +``` -

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

+## Configurer une référence à un dépôt distant -
git remote add nom-ref-distante url-du-depot-distant-a-referencer
+```bash +git remote add nom-ref-distante url-du-depot-distant-a-referencer +``` -

Afficher la liste des références distantes

+## Afficher la liste des références distantes -
git remote -v
+```bash +git remote -v +``` -

Préparer une modification du dépôt

+## Préparer une modification du dépôt -

Basculer sur la branche principale

+### Basculer sur la branche principale -
git switch main
+```bash +git switch main +``` -

Mettre à jour votre branche principale

+### Mettre à jour votre branche principale -
git fetch nom-ref-distante
-git rebase nom-ref-distante/main
-git push
+```bash +git fetch nom-ref-distante +git rebase nom-ref-distante/main +git push +``` -

Obtenir sa branche en local et basculer sur celle-ci

+## Obtenir sa branche en local et basculer sur celle-ci -
git pull
-git switch nouvelle-branche
+```bash +git pull +git switch nouvelle-branche +``` -

Obtenir le dernier statut

+## Obtenir le dernier statut -
git status
+```bash +git status +``` -

Ajouter, valider et pousser les changements

+## Ajouter, valider et pousser les changements -
git add chemin-fichier-modifie
+```bash
+git add chemin-fichier-modifie
 git commit -m 'mon message de commit'
-git push
+git push +``` -

Dépannage

+## Dépannage -

Annuler une modification non indexée

+### Annuler une modification non indexée -
git restore chemin-du-fichier
+```bash +git restore chemin-du-fichier +``` -

Retirer un fichier de l'index

+### Retirer un fichier de l'index -
git restore --staged chemin-du-fichier
+```bash +git restore --staged chemin-du-fichier +``` -

Annuler le dernier commit

+### Annuler le dernier commit -
git reset HEAD~1
+```bash +git reset HEAD~1 +``` -

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

+### Inverser un commit qui a été poussé vers la bifurcation distante -
git revert HEAD
-git push
+```bash +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 ».

-
+> **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 ?

+## 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.

+Si vous pensez que cet aide-mémoire devrait contenir plus de commandes, veuillez [créer un ticket](https://github.com/mdn/translated-content/issues/new) pour suggérer ce que vous pensez que nous devrions inclure. diff --git a/files/fr/mdn/contribute/help_beginners/index.md b/files/fr/mdn/contribute/help_beginners/index.md index 92c94bb627..93dafbb2dc 100644 --- a/files/fr/mdn/contribute/help_beginners/index.md +++ b/files/fr/mdn/contribute/help_beginners/index.md @@ -9,103 +9,79 @@ tags: - 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. -
  3. 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.
  4. -
- -

Comment pouvez-vous en profiter ?

- -
    -
  • Aider les gens à résoudre leurs problèmes de code est un excellent moyen d'en apprendre davantage sur les technologies web. En recherchant une solution et en rédigeant une réponse à la question de quelqu'un, vous approfondirez votre compréhension du sujet et améliorerez vos compétences.
  • -
  • Au fur et à mesure que vous vous impliquerez dans la communauté MDN, vous apprendrez à connaître le personnel de Mozilla et les autres membres de la communauté, ce qui vous donnera un réseau de contacts précieux pour obtenir de l'aide sur vos propres problèmes et accroître votre visibilité.
  • -
  • Aider à répondre à des questions de codage est en grande partie une récompense en soi, mais cela démontrera également votre expertise dans les technologies web et peut-être même vous aidera dans votre cours, ou dans vos opportunités d'emploi.
  • -
- -

Quelles sont les compétences dont vous avez besoin ?

- -
    -
  • Vous devez avoir une bonne connaissance des technologies web telles que HTML, CSS et JavaScript. Idéalement, vous devez aussi savoir expliquer des sujets techniques et aimer aider les débutants à apprendre à coder.
  • -
  • La langue du forum est l'anglais - vous devriez avoir une maîtrise raisonnable de la langue anglaise, mais il n'est pas nécessaire qu'elle soit parfaite. Des gens du monde entier visitent nos forums, et nous voulons que tous ceux qui nous rendent visite se sentent aussi à l'aise et inclus que possible.
  • -
- -

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. -
  3. Inscrivez-vous également à Mozilla Discourse, si ce n'est pas déjà fait.
  4. -
  5. 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).
  6. -
- -

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. -
  3. 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.
  4. -
  5. 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. -
    3. 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.
      • -
      -
    4. -
    5. 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. -
      3. Si non, pourquoi ne fonctionne-t-il pas ?
      4. -
      5. Avez-vous des conseils à donner à la personne pour améliorer le code (plus efficace, meilleure pratique, etc.) ?
      6. -
      -
    6. -
    7. 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. -
      3. 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.
      4. -
      5. 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.
      6. -
      7. 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.
      8. -
      9. 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.
      10. -
      -
    8. -
    -
  6. -
- -
-

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. -
  3. Regardez en particulier les types d'évaluations disponibles, - -
  4. -
  5. 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.
  6. -
  7. Chaque évaluation/épreuve de compétence est associée à un guide de notation et à une solution recommandée pour vous aider à évaluer leur travail.
  8. -
  9. Il existe des modèles qui facilitent la recherche de ces ressources, par exemple : - -
  10. -
- -

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.

+{{MDNSidebar}} + +Nos pages [Apprendre le développement web](/fr/docs/Learn) obtiennent plus d'un million de vues par mois, et ont [des forums actifs](https://discourse.mozilla.org/c/mdn/learn/250) 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](https://discourse.mozilla.org/c/mdn/learn/250), 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. 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. + +## Comment pouvez-vous en profiter ? + +- Aider les gens à résoudre leurs problèmes de code est un excellent moyen d'en apprendre davantage sur les technologies web. En recherchant une solution et en rédigeant une réponse à la question de quelqu'un, vous approfondirez votre compréhension du sujet et améliorerez vos compétences. +- Au fur et à mesure que vous vous impliquerez dans la communauté MDN, vous apprendrez à connaître le personnel de Mozilla et les autres membres de la communauté, ce qui vous donnera un réseau de contacts précieux pour obtenir de l'aide sur vos propres problèmes et accroître votre visibilité. +- Aider à répondre à des questions de codage est en grande partie une récompense en soi, mais cela démontrera également votre expertise dans les technologies web et peut-être même vous aidera dans votre cours, ou dans vos opportunités d'emploi. + +## Quelles sont les compétences dont vous avez besoin ? + +- Vous devez avoir une bonne connaissance des technologies web telles que HTML, CSS et JavaScript. Idéalement, vous devez aussi savoir expliquer des sujets techniques et aimer aider les débutants à apprendre à coder. +- La langue du forum est l'anglais - vous devriez avoir une maîtrise raisonnable de la langue anglaise, mais il n'est pas nécessaire qu'elle soit parfaite. Des gens du monde entier visitent nos forums, et nous voulons que tous ceux qui nous rendent visite se sentent aussi à l'aise et inclus que possible. + +## Comment aider + +1. Tout d'abord, [créez-vous un compte MDN](/fr/docs/MDN/Contribute/Getting_started#step_1_create_an_account_on_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. Inscrivez-vous également à [Mozilla Discourse](https://discourse.mozilla.org/), si ce n'est pas déjà fait. +3. Jetez un coup d'œil à la section [Apprendre le développement web](/fr/docs/Learn) 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](Structure_of_the_MDN_Learning_Area) ci-dessous pour vous aider). + +### Une fois que vous êtes prêt + +1. Jetez un coup d'œil au [forum d'apprentissage](https://discourse.mozilla.org/c/mdn/learn/250) 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. 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. 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. 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. 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. Si non, pourquoi ne fonctionne-t-il pas ? + 3. Avez-vous des conseils à donner à la personne pour améliorer le code (plus efficace, meilleure pratique, etc.) ? + + 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. 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. 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. 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. Si vous avez besoin d'aide pour quoi que ce soit, demandez de l'aide dans le salon de discussion [MDN Web Docs](https://chat.mozilla.org/#/room/#mdn:mozilla.org) sur [Matrix](https://wiki.mozilla.org/Matrix). + +> **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](/fr/docs/Learn) 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. Regardez en particulier les types d'évaluations disponibles, + + - À partir des nombreux articles "testez vos compétences" disponibles (voir par exemple [/fr/docs/Learn/JavaScript/Building_blocks/conditionals#Test_your_skills!](/fr/docs/Learn/JavaScript/Building_blocks/conditionals#test_your_skills!)) + - Aux évaluations plus approfondies à la fin de certains modules (voir par exemple [/fr/docs/Learn/JavaScript/Building_blocks/Image_gallery](/fr/docs/Learn/JavaScript/Building_blocks/Image_gallery)) + +3. Jetez un œil aux dépôts GitHub associés à la zone d'apprentissage (la plupart des fichiers sont disponibles dans , certains sont dans ). La plupart des exemples sur lesquels les apprenants voudront de l'aide sont contenus ici. +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. Il existe des modèles qui facilitent la recherche de ces ressources, par exemple : + + - Le guide de notation "testez vos compétences" ci-dessus et les ressources sont disponibles sur + - Le guide de notation de l'évaluation ci-dessus et les ressources sont disponibles sur + +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.md b/files/fr/mdn/contribute/howto/convert_code_samples_to_be_live/index.md index 5575715390..4ef023d508 100644 --- 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 @@ -4,24 +4,21 @@ 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.

+{{MDNSidebar}} -

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

+MDN dispose d'un système d'exemples "[live](/en-US/docs/MDN/Contribute/Editor/Live_samples)", 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. -

Compétences nécessaires pour cette tâche

+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". -
    -
  • Comprendre le HTML, CSS et/ou JavaScript, selon le code implémenté
  • -
  • Savoir utiliser les macros KumaScript dans les articles du MDN
  • -
+## Compétences nécessaires pour cette tâche -

Quelles étapes pour réaliser cette tâche ?

+- Comprendre le HTML, CSS et/ou JavaScript, selon le code implémenté +- Savoir utiliser les macros [KumaScript](/en-US/docs/Project:Introduction_to_KumaScript) dans les articles du MDN -
    -
  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. -
  3. Convertissez le code pour qu'il soit "live"
  4. -
  5. Supprimer le code ou l'image qui montrait les sorties et résultats du programme. Votre exemple "live" le remplace désormais.
  6. -
+## Quelles étapes pour réaliser cette tâche ? -

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

+1. Choisissez un article dans la liste de ceux marqués [NeedsLiveSample](/en-US/docs/tag/NeedsLiveSample), pour lequel le code présenté porte sur des notions qui vous sembles familières. +2. Convertissez le code pour qu'il soit "live" +3. Supprimer le code ou l'image qui montrait les sorties et résultats du programme. Votre exemple "live" le remplace désormais. + +Pour plus d'information sur la création et l'édition d'exemples "live", voir [Utiliser le système d'exemple "live"](/en-US/docs/Project:MDN/Contributing/Editor_guide/Live_samples) (en anglais). 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 index 70cb353739..68fc903f39 100644 --- a/files/fr/mdn/contribute/howto/create_and_edit_pages/index.md +++ b/files/fr/mdn/contribute/howto/create_and_edit_pages/index.md @@ -1,44 +1,47 @@ --- title: Créer et modifier des pages slug: MDN/Contribute/Howto/Create_and_edit_pages -translation_of: 'MDN/Contribute/Howto/Create_and_edit_pages' +translation_of: MDN/Contribute/Howto/Create_and_edit_pages --- -
{{MDNSidebar}}
+{{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.

+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

+> **Note :** Le contenu de MDN s'organise au sein de deux dépôts Git : [`mdn/content`](https://github.com/mdn/content) avec le contenu en anglais et [`mdn/translated-content`](https://github.com/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. -

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

+## Modifier une page existante -

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.

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

Prévisualiser vos modifications

+- Si elle est en anglais : [sur notre dépôt content](https://github.com/mdn/content) -

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.

+ content -

Ajouter des pièces jointes

+- Si elle est en français ou dans une autre langue : [sur notre dépôt translated-content](https://github.com/mdn/translated-content) -

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

+ translated-content -

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

+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 ». -
-

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

+Une fois que vous avez trouvé la source à modifier, rendez-vous sur notre fichier README et parcourez notre [guide sur la contribution (en anglais)](https://github.com/mdn/translated-content/#making-contributions). Vous pouvez également consulter [ce billet en français](https://tech.mozfr.org/post/2021/03/16/MDN-sur-GitHub-comment-contribuer) 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 ``. + +## 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)](https://github.com/mdn/content#adding-a-new-document). + +> **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 + +- [Guide stylistique de MDN](/fr/docs/MDN/Guidelines/Writing_style_guide) +- [MDN sur GitHub : comment contribuer ?](https://tech.mozfr.org/post/2021/03/16/MDN-sur-GitHub-comment-contribuer) diff --git a/files/fr/mdn/contribute/howto/index.md b/files/fr/mdn/contribute/howto/index.md index 59b33bbba6..77a41256ec 100644 --- a/files/fr/mdn/contribute/howto/index.md +++ b/files/fr/mdn/contribute/howto/index.md @@ -6,8 +6,8 @@ tags: - MDN Meta translation_of: MDN/Contribute/Howto --- -
{{MDNSidebar}}
{{IncludeSubnav("/fr/docs/MDN")}}
+{{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.

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

{{LandingPageListSubpages}}

+{{LandingPageListSubpages}} 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 index b70818e6d9..d518794b83 100644 --- 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 @@ -8,105 +8,72 @@ tags: - MDN Méta(2) translation_of: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary --- -
{{MDNSidebar}}
+{{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.

+Le [glossaire](/fr/docs/Glossary) 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

+## 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.

+Pour trouver des sujets ayant besoin d'entrées de glossaire, consultez la [liste des termes à documenter ](/fr/docs/Glossary#Contribute_to_the_glossary)à 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é

+### É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é.

+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 :** 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.

-
+> **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}}).

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

+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](/fr/docs/MDN/Community#Join_our_mailing_lists). -

Étape 2 : offrir d'autres sources

+### É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.

+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 :

+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.
-
+- Connaissance générale + - : Liens qui fournissent plus d'information générale ; par exemple, un lien vers [Wikipédia](http://fr.wikipedia.org/) 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

+## 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 !

+Vous désirez contribuer mais vous ignorez quel terme doit être défini ? [Voici une liste](https://developer.mozilla.org/fr/docs/Glossary#Contribute_to_the_glossary) de suggestions. Cliquez un mot et lancez-vous ! -

Gérer les ambiguïtés

+## 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 :

+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 : -
    -
  • La page principale du terme doit être une page de « désambiguïsation » contenant la macro {{TemplateLink("GlossaryDisambiguation")}}.
  • -
  • Des sous-pages définissent ensuite le terme dans chacun de ses contextes propres.
  • -
+- La page principale du terme doit être une page de « désambiguïsation » contenant la macro {{TemplateLink("GlossaryDisambiguation")}}. +- Des sous-pages définissent ensuite le terme dans chacun de ses contextes propres. -

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.

+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. -
  3. La sous-page Glossaire/Signature/Sécurité est la page définissant le terme dans le contexte de la sécurité informatique.
  4. -
  5. La sous-page Glossaire/Signature/Fonction est la page définissant les signatures de fonction.
  6. -
  7. La sous-page Glossaire/Signature/Mèl est la page définissant les signatures de mèl.
  8. -
+1. La page [Glossaire/Signature](/fr/docs/Glossary/Signature) est la page de « désambiguïsation » avec la macro {{TemplateLink("GlossaryDisambiguation")}} macro. +2. La sous-page [Glossaire/Signature/Sécurité](/fr/docs/Glossary/Signature/Security) est la page définissant le terme dans le contexte de la sécurité informatique. +3. La sous-page [Glossaire/Signature/Fonction](/fr/docs/Glossary/Signature/Function) est la page définissant les _signatures de fonction_. +4. La sous-page [Glossaire/Signature/Mèl](/en-US/docs/Glossary/Signature/Email) est la page définissant les signatures de mèl. -

Utiliser la macro \{{Glossary}}

+## 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")}} :

+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.
+| Macro | Result | Note | +| ---------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| \\{{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).

+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

+### 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 :

+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 : -
    -
  • Si un terme est déjà lié à une autre partie de MDN, n'y touchez pas et n'utilisez pas la macro \{{Glossary}}.
  • -
  • À l'intérieur d'une même section d'article, n'utilisez la macro \{{Glossary}} qu'une seule fois pour le même terme (astuce : une section commence toujours par un titre).
  • -
+- Si un terme est déjà lié à une autre partie de MDN, n'y touchez pas et n'utilisez pas la macro \\{{Glossary}}. +- À l'intérieur d'une même section d'article, n'utilisez la macro \\{{Glossary}} qu'une seule fois pour le même terme (_astuce : une section commence toujours par un titre_). diff --git a/files/fr/mdn/contribute/index.md b/files/fr/mdn/contribute/index.md index f72eae7a86..a5ebdbe3c1 100644 --- a/files/fr/mdn/contribute/index.md +++ b/files/fr/mdn/contribute/index.md @@ -7,23 +7,21 @@ tags: - MDN Meta translation_of: MDN/Contribute --- -
{{MDNSidebar}}
+{{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.

+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 » !

-
+> **Note :** Si vous n'avez jamais contribué à MDN auparavant, le guide [Pour commencer](/fr/docs/MDN/Contribute/Getting_started) 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 ?

+## 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.

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

+Si vous n'êtes pas sûr de ce que vous devez faire, vous êtes toujours invité à [demander de l'aide](/fr/docs/MDN/Contribute/Getting_started#step_4_ask_for_help). -

Principaux types de contributions

+### 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.

+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. @@ -35,78 +33,138 @@ translation_of: MDN/Contribute - - + + - - + + - - + +
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. + Correction des bogues de contenu MDN + + Notre 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).
  • +
  • + 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. + Révision des éditions du MDN + + Les 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).
  • +
  • + 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. + Aider les débutants à apprendre sur MDN + + Nos 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.
  • +
  • + 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.

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

Notation des priorités

+#### 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.

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

+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](/fr/docs/MDN/Contribute/Documentation_priorities). -

Autres types de tâches

+### 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 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 les mots, vous pouvez faire ce qui suit : - +- [Mettre à jour un article existant avec de nouvelles informations](/fr/docs/MDN/Contribute/Howto/Create_and_edit_pages#editing_an_existing_page) (5 minutes-1 heure) +- [Rédiger une nouvelle entrée dans le glossaire](/fr/docs/MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary) (15 minutes-1 heure) -

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

+Si vous êtes plus intéressé par le code, vous pouvez vous essayer à ce qui suit : - +- [Convertir les échantillons de code pour qu'ils soient « en direct »](/fr/docs/MDN/Contribute/Howto/Convert_code_samples_to_be_live) (30 minutes) +- [Envoyez un correctif de code à la base de code de Yari](https://github.com/mdn/yari) (1 heure) +- [Écrire un exemple interactif](https://github.com/mdn/interactive-examples/blob/master/CONTRIBUTING.md) (1 heure) -

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

+Si vous vous intéressez aux mots _et_ au code, vous pourriez vous essayer à ce qui suit : - +- [Rédiger ou mettre à jour une référence API](/fr/docs/MDN/Contribute/Howto/Write_an_API_reference) (30 minutes à 2 heures, ou plus) +- [Rédiger un nouvel article sur un sujet qui vous est familier](https://github.com/mdn/content#adding-a-new-document) (1 heure ou plus) +- [Ajouter ou mettre à jour les données de compatibilité des navigateurs sur une page de référence](/fr/docs/MDN/Structures/Compatibility_tables) (30 minutes à 1 heure) -
-

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.

-
+> **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](https://github.com/mdn/content/issues/new). 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

+## Autres pages utiles -

{{LandingPageListSubPages()}}

+{{LandingPageListSubPages()}} diff --git a/files/fr/mdn/contribute/localize/index.md b/files/fr/mdn/contribute/localize/index.md index bd39293888..796f19ff89 100644 --- a/files/fr/mdn/contribute/localize/index.md +++ b/files/fr/mdn/contribute/localize/index.md @@ -6,66 +6,52 @@ tags: - MDN Meta - l10n --- -
{{MDNSidebar}}
+{{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.

+Depuis le 14 décembre 2020, MDN fonctionne sur la nouvelle plateforme [Yari](https://github.com/mdn/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.

+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

+## Langues actives -

Nous avons actuellement dégelé les langues suivantes :

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

-
+> **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](/fr/docs/MDN/Contribute/Getting_started#step_4_ask_for_help). -

Chinois (zh-CN, zh-TW)

+### Chinois (zh-CN, zh-TW) - +- Discussions : [Telegram (MozTW L10n channel)](https://moztw.org/tg) +- Contributeurs actuels : [Irvin](https://github.com/irvin), [t7yang](https://github.com/t7yang), [dibery](https://github.com/dibery) -

Français (fr)

+### Français (fr) - +- Discussions : [Matrix (#l10n-fr channel)](https://chat.mozilla.org/#/room/#l10n-fr:mozilla.org) +- Contributeurs actuels : [SphinxKnight](https://github.com/SphinxKnight), [tristantheb](https://github.com/tristantheb), [Jb Audras](https://github.com/audrasjb) -

Japonais (ja)

+### Japonais (ja) - +- Discussions : [Slack (#translation channel)](https://mozillajp.slack.com/), [GitHub (mozilla-japan)](https://github.com/mozilla-japan/translation), [Google Group (Mozilla.translations.ja)](https://groups.google.com/forum/#!forum/mozilla-translations-ja) +- Contributeurs actuels : [mfuji09](https://github.com/mfuji09), [hmatrjp](https://github.com/hmatrjp), [potappo](https://github.com/potappo), [dynamis](https://github.com/dynamis), [kenji-yamasaki](https://github.com/kenji-yamasaki) -

Coréen (ko)

+### Coréen (ko) - +- Discussions : [Kakao Talk (#MDN Korea)](https://open.kakao.com/o/gdfG288c) +- Contributeurs actuels : [hochan222](https://github.com/hochan222), [yechoi42](https://github.com/yechoi42), [cos18](https://github.com/cos18), [GwangYeol-Im](https://github.com/GwangYeol-Im), [pje1740](https://github.com/pje1740), [nKiNk](https://github.com/nKiNk), [yujo11](https://github.com/yujo11) -

Russe (ru)

+### Russe (ru) - +- Discussions : [Matrix (#mdn-l10n-ru channel)](https://chat.mozilla.org/#/room/#mdn-l10n-ru:mozilla.org) +- Contributeurs actuels : [armanpwnz](https://github.com/armanpwnz), [captainspring](https://github.com/captainspring), [mpstv](https://github.com/mpstv), [myshov](https://github.com/myshov), [Saionaro](https://github.com/Saionaro), [sashasushko](https://github.com/sashasushko), [lex111](https://github.com/lex111) -

Autres sujets de localisation sur MDN

+## 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.

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

+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](https://github.com/mdn/yari/tree/main/kumascript/macros). -

Voir aussi

+## Voir aussi - +- [MDN localization in March — Tier 1 locales unfrozen, and future plans](https://hacks.mozilla.org/2021/03/mdn-localization-in-march-tier-1-locales-unfrozen-and-future-plans/) — les prévisions pour le dégel des prochaines langues et des informations sur les langues qui seront supprimées. +- [MDN localization update, February 2021](https://hacks.mozilla.org/mdn-localization-update-february-2021/) — le dernier état de la localisation sur MDN. +- [An update on MDN Web Docs' localization strategy](https://hacks.mozilla.org/an-update-on-mdn-web-docs-localization-strategy/) — stratégie actualisée sur la base des réactions de la communauté. +- [MDN Web Docs evolves! Lowdown on the upcoming new platform](https://hacks.mozilla.org/mdn-web-docs-evolves-lowdown-on-the-upcoming-new-platform/) — plus d'informations sur les avantages de la nouvelle plateforme et sur les raisons des changements de localisation. diff --git a/files/fr/mdn/contribute/open_source_etiquette/index.md b/files/fr/mdn/contribute/open_source_etiquette/index.md index 2721c7985c..f5328823f8 100644 --- a/files/fr/mdn/contribute/open_source_etiquette/index.md +++ b/files/fr/mdn/contribute/open_source_etiquette/index.md @@ -9,157 +9,139 @@ tags: - Beginners translation_of: MDN/Contribute/Open_source_etiquette --- -

{{MDNSidebar}}

+{{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.

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

+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

+## 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.

+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 :

+De meilleures raisons encore peuvent être envisagées : -

    -
  • J'utilise cet outil en permanence et j'ai trouvé un bogue dans celui-ci/je veux contribuer à son amélioration.
  • -
  • Je veux aider d'autres personnes à utiliser cet outil avec plus de facilité.
  • -
  • Je veux aider d'autres personnes à contribuer au projet avec plus de facilité.
  • -
  • Je veux améliorer mes propres compétences.
  • -
  • Je veux démontrer publiquement mes propres compétences dans le cadre de mon cursus universitaire ou collégial.
  • -
  • Je veux démontrer publiquement mes propres compétences pour améliorer mes chances de trouver un emploi.
  • -
+- J'utilise cet outil en permanence et j'ai trouvé un bogue dans celui-ci/je veux contribuer à son amélioration. +- Je veux aider d'autres personnes à utiliser cet outil avec plus de facilité. +- Je veux aider d'autres personnes à contribuer au projet avec plus de facilité. +- Je veux améliorer mes propres compétences. +- Je veux démontrer publiquement mes propres compétences dans le cadre de mon cursus universitaire ou collégial. +- Je veux démontrer publiquement mes propres compétences pour améliorer mes chances de trouver un emploi. -

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.

+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 :

+Voici quelques raisons pour lesquelles vous ne devriez pas commencer à contribuer : -
    -
  • Je veux quelqu'un à qui parler.
  • -
  • Je veux des gens à troller ou à diriger.
  • -
  • Je veux montrer à quel point je suis incroyable.
  • -
+- Je veux quelqu'un à qui parler. +- Je veux des gens à troller ou à diriger. +- Je veux montrer à quel point je suis incroyable. -

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

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

+## 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.

+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 :

+Soyez gentil avec les autres contributeurs du projet, et le projet sera plus agréable et plus productif. Cela inclut : -
    -
  • Remercier les gens s'ils vous aident.
  • -
  • Féliciter les personnes lorsque cela est approprié (par exemple, si elles déposent leur toute première demande de révision ou si elles résolvent un bogue particulièrement difficile).
  • -
  • Toujours répondre respectueusement aux gens, même si vous avez l'impression que la réponse à leur question était un peu évidente, ou qu'ils se répètent.
  • -
  • Essayer d'aider les gens à faire mieux la prochaine fois, en les soutenant, par exemple lors de l'examen des demandes de modification ou en répondant à leurs questions. Dire « c'est faux » ou « voici la réponse » est loin d'être aussi utile que de dire « c'est correct, mais je pense que ce serait mieux si vous essayiez de faire plus comme ceci, voici un article de blog pour plus d'idées » ou « vous pouvez trouver la réponse ici ; consultez également ce lien pour des réponses plus courantes ».
  • -
+- Remercier les gens s'ils vous aident. +- Féliciter les personnes lorsque cela est approprié (par exemple, si elles déposent leur toute première demande de révision ou si elles résolvent un bogue particulièrement difficile). +- Toujours répondre respectueusement aux gens, même si vous avez l'impression que la réponse à leur question était un peu évidente, ou qu'ils se répètent. +- Essayer d'aider les gens à faire mieux la prochaine fois, en les soutenant, par exemple lors de l'examen des demandes de modification ou en répondant à leurs questions. Dire « c'est faux » ou « voici la réponse » est loin d'être aussi utile que de dire « c'est correct, mais je pense que ce serait mieux si vous essayiez de faire plus comme ceci, voici un article de blog pour plus d'idées » ou « vous pouvez trouver la réponse ici ; consultez également ce lien pour des réponses plus courantes ». -

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 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 : -
    -
  • Connaissance du projet et des technologies utilisées pour le construire
  • -
  • Sexe, sexualité, âge, langues parlées, lieu de résidence, opinions politiques, religion ou autres caractéristiques personnelles
  • -
  • Expérience des projets open source
  • -
  • Confiance
  • -
  • Attentes
  • -
  • Sens de l'humour
  • -
+- Connaissance du projet et des technologies utilisées pour le construire +- Sexe, sexualité, âge, langues parlées, lieu de résidence, opinions politiques, religion ou autres caractéristiques personnelles +- Expérience des projets open source +- Confiance +- Attentes +- Sens de l'humour -

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.

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

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

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

+Par exemple, les dépôts du MDN sont régis par les vastes [Mozilla Community Participation Guidelines](https://www.mozilla.org/fr/about/governance/policies/participation/). 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.

+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

+## 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é.

+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 , 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.

+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 :

+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 : -
    -
  • Aidez à trier les problèmes qui arrivent.
  • -
  • Aidez à corriger les fautes de frappe.
  • -
  • Aider à améliorer la grammaire et à rendre les pages plus compréhensibles.
  • -
  • Aidez à encadrer les personnes qui essaient de corriger les problèmes.
  • -
+- Aidez à trier les problèmes qui arrivent. +- Aidez à corriger les fautes de frappe. +- Aider à améliorer la grammaire et à rendre les pages plus compréhensibles. +- Aidez à encadrer les personnes qui essaient de corriger les problèmes. -

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 :

+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 : -
    -
  • Mettre à jour le style du code juste parce que "vous préférez ce style".
  • -
  • Mettre à jour le style de la langue "juste parce que vous aimez mieux ce style".
  • -
  • Changer les pages de l'anglais américain à l'anglais britannique.
  • -
  • Ajouter ou enlever un tas de ponctuation alors qu'il n'y a pas vraiment de problème.
  • -
  • Changer le cadre de test que nous utilisons pour quelque chose d'autre parce que vous le préférez.
  • -
+- Mettre à jour le style du code juste parce que "vous préférez ce style". +- Mettre à jour le style de la langue "juste parce que vous aimez mieux ce style". +- Changer les pages de l'anglais américain à l'anglais britannique. +- Ajouter ou enlever un tas de ponctuation alors qu'il n'y a pas vraiment de problème. +- Changer le cadre de test que nous utilisons pour quelque chose d'autre parce que vous le préférez. -

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 !

+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

+## 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).

+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](https://github.com/mdn/translated-content/blob/main/README.md) et d'un ensemble décent de docs pour les contributeurs sur le site lui-même (voir [Contribuer à MDN](/fr/docs/MDN/Contribute)). -

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.

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

+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

+## 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).

+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](/fr/docs/MDN/Contribute/Getting_started#step_4_ask_for_help)). 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

+## 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 ?

+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 :

+En règle générale, faites ceci : -
    -
  • Discutez d'un seul sujet par question - il est facile de garder les questions ciblées et productives.
  • -
  • Corrigez un problème par PR - cela peut représenter un peu plus de travail pour vous, mais il est beaucoup plus facile d'examiner une seule correction claire.
  • -
  • Contribuez à d'autres fils de discussion si vous avez une remarque utile à faire ou si vous pouvez répondre à la question d'une autre personne.
  • -
  • Posez des questions en utilisant d'autres mécanismes comme les salons de discussion ou les forums si vous n'êtes pas sûr de l'utilité de quelque chose ou si vous avez une question simple.
  • -
  • Lisez d'abord le guide pour essayer de répondre vous-même à la question avant de la poser.
  • -
+- Discutez d'un seul sujet par question - il est facile de garder les questions ciblées et productives. +- Corrigez un problème par PR - cela peut représenter un peu plus de travail pour vous, mais il est beaucoup plus facile d'examiner une seule correction claire. +- Contribuez à d'autres fils de discussion si vous avez une remarque utile à faire ou si vous pouvez répondre à la question d'une autre personne. +- Posez des questions en utilisant d'autres mécanismes comme les salons de discussion ou les forums si vous n'êtes pas sûr de l'utilité de quelque chose ou si vous avez une question simple. +- Lisez d'abord le guide pour essayer de répondre vous-même à la question avant de la poser. -

Et pas :

+Et pas : -
    -
  • Compliquez les choses en essayant de discuter de plusieurs sujets à la fois, ou en faisant des commentaires hors sujet.
  • -
  • Essayer de regrouper plusieurs corrections dans une seule demande de triage. Cela rend la révision beaucoup plus difficile et éveille les soupçons (certaines personnes pourraient penser que vous essayez de cacher un code malveillant entre les changements valides).
  • -
  • Ouvrir beaucoup de tickets en posant des questions vagues.
  • -
  • Posez des questions sans essayer d'abord de résoudre le problème vous-même.
  • -
+- Compliquez les choses en essayant de discuter de plusieurs sujets à la fois, ou en faisant des commentaires hors sujet. +- Essayer de regrouper plusieurs corrections dans une seule demande de triage. Cela rend la révision beaucoup plus difficile et éveille les soupçons (certaines personnes pourraient penser que vous essayez de cacher un code malveillant entre les changements valides). +- Ouvrir beaucoup de tickets en posant des questions vagues. +- Posez des questions sans essayer d'abord de résoudre le problème vous-même. -

Les OSP sont une démocratie (ou presque)

+## 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.

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

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

+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

+## 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.

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

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

+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

+## Voir aussi - +- [Comment contribuer à l'Open Source](https://opensource.guide/how-to-contribute/) +- [Liste plus générale de freeCodeCamp « Comment contribuer à l'open source ».](https://github.com/freeCodeCamp/how-to-contribute-to-open-source) +- [Commencer à contribuer à l'open source](https://stackoverflow.blog/2020/08/03/getting-started-with-contributing-to-open-source/) diff --git a/files/fr/mdn/contribute/processes/index.md b/files/fr/mdn/contribute/processes/index.md index ffc1cf92a3..68cb055db9 100644 --- a/files/fr/mdn/contribute/processes/index.md +++ b/files/fr/mdn/contribute/processes/index.md @@ -7,10 +7,10 @@ tags: - Processes translation_of: MDN/Contribute/Processes --- -
{{MDNSidebar}}
+{{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.

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

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

{{LandingPageListSubPages()}}

+{{LandingPageListSubPages()}} diff --git a/files/fr/mdn/contribute/where_is_everything/index.md b/files/fr/mdn/contribute/where_is_everything/index.md index 349a70a3fb..c6dbde0480 100644 --- a/files/fr/mdn/contribute/where_is_everything/index.md +++ b/files/fr/mdn/contribute/where_is_everything/index.md @@ -10,26 +10,22 @@ tags: - Repos translation_of: MDN/Contribute/Where_is_everything --- -

{{MDNSidebar}}

+{{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.

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

+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

+## Dépôts principaux -
    -
  • Contenu de référence (anglais) : https://github.com/mdn/content. Le dépôt le plus important pour le contenu MDN : c'est là qu'est stocké le contenu principal en anglais du site et que vous effectuerez toutes les modifications standard du contenu des pages.
  • -
  • Plateforme MDN : https://github.com/mdn/yari. C'est là que la plateforme MDN est stockée, et c'est là que vous irez si vous souhaitez apporter des modifications à la structure de haut niveau des pages de MDN ou aux mécanismes de rendu.
  • -
  • Données de compatibilité des navigateurs : https://github.com/mdn/browser-compat-data. C'est ici que sont stockées les données utilisées pour générer les tableaux de compatibilité des navigateurs que l'on trouve sur nos pages de référence. Allez ici pour modifier les données de compatibilité !
  • -
  • Exemples interactifs : https://github.com/mdn/interactive-examples. Ce dépôt stocke le code de rendu et les blocs de code d'exemple qui, ensemble, produisent les beaux exemples modifiables et copiables que l'on trouve en haut de beaucoup de nos pages de référence. Éditez ces exemples ici.
  • -
  • Contenu traduit : https://github.com/mdn/translated-content. C'est ici que vit le contenu localisé. Allez ici si vous voulez aider à maintenir les locales de niveau 1 que nous avons actuellement dégelées (actuellement fr, ja, ko, zh-CN/zh-TW et ru). Nous n'autorisons actuellement pas les éditions pour d'autres locales.
  • -
  • Données CSS : https://github.com/mdn/data. Conçu à l'origine comme un dépôt de données MDN à usage général, le dépôt de données sert désormais à conserver les données relatives aux fonctionnalités CSS telles que la syntaxe formelle, l'héritage, la valeur calculée, le type d'animation, etc. Ces données sont utilisées pour générer des sections sur les pages de référence CSS telles que la définition formelle et la syntaxe formelle.
  • -
+- **Contenu de référence (anglais)** : . Le dépôt le plus important pour le contenu MDN : c'est là qu'est stocké le contenu principal en anglais du site et que vous effectuerez toutes les modifications standard du contenu des pages. +- **Plateforme MDN** : . C'est là que la plateforme MDN est stockée, et c'est là que vous irez si vous souhaitez apporter des modifications à la structure de haut niveau des pages de MDN ou aux mécanismes de rendu. +- **Données de compatibilité des navigateurs** : . C'est ici que sont stockées les données utilisées pour générer les tableaux de compatibilité des navigateurs que l'on trouve sur nos pages de référence. Allez ici pour modifier les données de compatibilité ! +- **Exemples interactifs** : . Ce dépôt stocke le code de rendu et les blocs de code d'exemple qui, ensemble, produisent les beaux exemples modifiables et copiables que l'on trouve en haut de beaucoup de nos pages de référence. Éditez ces exemples ici. +- **Contenu traduit** : . C'est ici que vit le contenu localisé. Allez ici si vous voulez aider à maintenir les locales de niveau 1 que nous avons actuellement dégelées (actuellement `fr`, `ja`, `ko`, `zh-CN`/`zh-TW` et `ru`). Nous n'autorisons actuellement pas les éditions pour d'autres locales. +- **Données CSS** : . Conçu à l'origine comme un dépôt de données MDN à usage général, le dépôt de données sert désormais à conserver les données relatives aux fonctionnalités CSS telles que la syntaxe formelle, l'héritage, la valeur calculée, le type d'animation, etc. Ces données sont utilisées pour générer des sections sur les pages de référence CSS telles que la définition formelle et la syntaxe formelle. -

Autres dépôts

+## Autres dépôts -
    -
  • Dépôts des démonstrations : L'organisation GitHub de MDN contient un très grand nombre de dépôts de démonstration, par exemple css-examples, dom-examples, webaudio-examples. Elles contiennent généralement des exemples autonomes qui sont souvent liés à des pages MDN, mais vous trouverez parfois l'un de ces exemples intégré à une page à l'aide d'un appel de macro comme celui-ci - \{{EmbedGHLiveSample("css-examples/learn/tasks/grid/grid1.html", '100%', 700)}}. Si vous souhaitez modifier un exemple dynamique autonome, vous le trouverez toujours dans l'un de ces dépôts d'exemples.
  • -
  • MDN-minimaliste : https://github.com/mdn/mdn-minimalist. Les informations de style de base pour MDN. Si vous souhaitez contribuer à améliorer le style CSS de MDN, c'est ici que vous devez vous rendre.
  • -
+- **Dépôts des démonstrations** : L'organisation GitHub de MDN contient un très grand nombre de dépôts de démonstration, par exemple [css-examples](https://github.com/mdn/css-examples), [dom-examples](https://github.com/mdn/dom-examples), [webaudio-examples](https://github.com/mdn/webaudio-examples). Elles contiennent généralement des exemples autonomes qui sont souvent liés à des pages MDN, mais vous trouverez parfois l'un de ces exemples intégré à une page à l'aide d'un appel de macro comme celui-ci - \\{{EmbedGHLiveSample("css-examples/learn/tasks/grid/grid1.html", '100%', 700)}}. Si vous souhaitez modifier un exemple dynamique autonome, vous le trouverez toujours dans l'un de ces dépôts d'exemples. +- **MDN-minimaliste** : . Les informations de style de base pour MDN. Si vous souhaitez contribuer à améliorer le style CSS de MDN, c'est ici que vous devez vous rendre. diff --git a/files/fr/mdn/guidelines/code_guidelines/css/index.md b/files/fr/mdn/guidelines/code_guidelines/css/index.md index 2e2a768762..b37d9b6f10 100644 --- a/files/fr/mdn/guidelines/code_guidelines/css/index.md +++ b/files/fr/mdn/guidelines/code_guidelines/css/index.md @@ -9,194 +9,205 @@ tags: - MDN Meta translation_of: MDN/Guidelines/Code_guidelines/CSS --- -
{{MDNSidebar}}
+{{MDNSidebar}} -

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

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

Dans cet article

+## Dans cet article - + - [N'utilisez pas de préprocesseurs](#dont_use_preprocessors) + - [N'utilisez pas de méthodologies CSS spécifiques](#dont_use_specific_css_methodologies) + - [Utiliser des unités flexibles/relatives](#use_flexiblerelative_units) + - [Ne pas utiliser de réinitialisation](#dont_use_resets) + - [Planifiez votre CSS — évitez les surcharges](#plan_your_css_%e2%80%94_avoid_overriding) -

Lignes directrices de haut niveau

+- [Style général de codage CSS](#general_css_coding_style) -

N'utilisez pas de préprocesseurs

+ - [Utiliser une syntaxe étendue](#use_expanded_syntax) + - [Privilégiez les règles longues aux règles raccourcies](#favor_longhand_rules_over_terse_shorthand) + - [Utilisez des guillemets doubles autour des valeurs](#use_double_quotes_around_values) + - [Espacement autour des paramètres de la fonction](#spacing_around_function_parameters) + - [Commentaires CSS](#css_comments) + - [Ne pas utiliser !important](#dont_use_!important) -

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.

+- [Points de syntaxe CSS spécifiques](#specific_css_syntax_points) -

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

+ - [Désactiver les bordures et autres propriétés](#turning_off_borders_and_other_properties) + - [Utilisez des requêtes média "mobile first"](#use_mobile_first_media_queries) -

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.

+- [Sélecteurs](#selectors) -

Utiliser des unités flexibles/relatives

+ - [N'utilisez pas de sélecteurs ID](#dont_use_id_selectors) + - [Mettre les sélecteurs multiples sur des lignes séparées](#put_multiple_selectors_on_separate_lines) -

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

+## Lignes directrices de haut niveau -

Ne pas utiliser de réinitialisation

+### N'utilisez pas de préprocesseurs -

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.

+N'utilisez pas la syntaxe des préprocesseurs, ex. [Sass](https://sass-lang.com/), [Less](http://lesscss.org/), ou [Stylus,](http://stylus-lang.com/) 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. -

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.

+### N'utilisez pas de méthodologies CSS spécifiques -

Planifiez votre CSS — évitez les surcharges

+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](http://getbem.com/naming/) ou [SMACSS](https://smacss.com/). 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. -

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.

+### Utiliser des unités flexibles/relatives -

Style général de codage CSS

+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)](/fr/docs/Web/Progressive_web_apps/Responsive/responsive_design_building_blocks#fluid_grids). -

Utiliser une syntaxe étendue

+### Ne pas utiliser de réinitialisation -

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.

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

Utilisez ceci :

+Si vous avez vraiment envie d'utiliser une réinitialisation, envisagez d'utiliser [normalize.css de Nicolas Gallagher](https://necolas.github.io/normalize.css/), 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 ``, par exemple) et à corriger quelques bogues. -
p {
+### 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 :
+
+```css example-good
+p {
   color: white;
   background-color: black;
   padding: 1rem;
-}
+} +``` -

Pas cela :

+Pas cela : -
p { color: white; background-color: black; padding: 1rem; }
+```css example-bad +p { color: white; background-color: black; padding: 1rem; } +``` -

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

+En outre, gardez ces spécificités à l'esprit : -
    -
  • Insérez un espace entre le(s) sélecteur(s) et l'accolade ouvrante.
  • -
  • Incluez toujours un point-virgule à la fin de la dernière déclaration, même si ce n'est pas strictement nécessaire.
  • -
  • Mettez l'accolade de fermeture sur une nouvelle ligne.
  • -
  • Dans chaque déclaration, mettez un espace après les deux points de séparation, mais pas avant.
  • -
  • Utilisez 2 espaces pour l'indentation du code.
  • -
+- Insérez un espace entre le(s) sélecteur(s) et l'accolade ouvrante. +- Incluez toujours un point-virgule à la fin de la dernière déclaration, même si ce n'est pas strictement nécessaire. +- Mettez l'accolade de fermeture sur une nouvelle ligne. +- Dans chaque déclaration, mettez un espace après les deux points de séparation, mais pas avant. +- Utilisez 2 espaces pour l'indentation du code. -

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

+### 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.

+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 :

+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`](/fr/docs/Web/CSS/font), par exemple : -
font: small-caps bold 2rem/1.5 sans-serif;
+```css +font: small-caps bold 2rem/1.5 sans-serif; +``` -

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

+Alors que celle-ci est plus immédiate en termes de compréhension : -
font-variant: small-caps;
+```css
+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
+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`](/fr/docs/Web/CSS/grid) définit toutes les valeurs par défaut suivantes pour les éléments qui ne sont pas spécifiés :
+
+- [`grid-template-rows`](/fr/docs/Web/CSS/grid-template-rows): `none`
+- [`grid-template-columns`](/fr/docs/Web/CSS/grid-template-columns): `none`
+- [`grid-template-areas`](/fr/docs/Web/CSS/grid-template-areas): `none`
+- [`grid-auto-rows`](/fr/docs/Web/CSS/grid-auto-rows): `auto`
+- [`grid-auto-columns`](/fr/docs/Web/CSS/grid-auto-columns): `auto`
+- [`grid-auto-flow`](/fr/docs/Web/CSS/grid-auto-flow): `row`
+- [`column-gap`](/fr/docs/Web/CSS/column-gap): `0`
+- [`row-gap`](/fr/docs/Web/CSS/row-gap): `0`
+- [`column-gap`](/fr/docs/Web/CSS/column-gap): `normal`
+- [`row-gap`](/fr/docs/Web/CSS/row-gap): `normal`
+
+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 :
+
+```css
+/* duration | timing-function | delay | iteration-count
    direction | fill-mode | play-state | name */
-animation: 3s ease-in 1s 2 reverse both paused slidein;
+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.

+À titre d'exemple, la première valeur qui peut être analysée comme un [`