Remove Mozilla/Developer_guide (#691)

9 files changed, 0 insertions, 619 deletions

diff --git a/files/fr/_redirects.txt b/files/fr/_redirects.txt
index 75e06f63bb..b244e30177 100644
--- a/files/fr/_redirects.txt
+++ b/files/fr/_redirects.txt
@@ -868,7 +868,6 @@
 /fr/docs/Colonnes_CSS3	/fr/docs/Web/CSS/CSS_Columns/Using_multi-column_layouts
 /fr/docs/Commencer_avec_le_WebGL	/fr/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL
 /fr/docs/Comment_créer_un_arbre_DOM	/fr/docs/Web/API/Document_object_model/How_to_create_a_DOM_tree
-/fr/docs/Compilation_et_installation	/fr/docs/Mozilla/Developer_guide/Build_Instructions
 /fr/docs/Components	/fr/docs/L'objet_Components
 /fr/docs/Comprendre_le_z-index_en_CSS	/fr/docs/Web/CSS/CSS_Positioning/Understanding_z_index
 /fr/docs/Comprendre_le_z-index_en_CSS/Ajout_de_z-index	/fr/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Adding_z-index
@@ -1224,18 +1223,13 @@
 /fr/docs/Dessin_de_texte_avec_canvas	/fr/docs/Web/API/Canvas_API/Tutorial/Drawing_text
 /fr/docs/Dessiner_avec_canvas	/fr/docs/conflicting/Web/API/Canvas_API/Tutorial
 /fr/docs/Detection_du_navigateur_en_utilisant_le_user_agent	/fr/docs/Web/HTTP/Browser_detection_using_the_user_agent
-/fr/docs/Developer_Guide	/fr/docs/Mozilla/Developer_guide
-/fr/docs/Developer_Guide/How_to_Submit_a_Patch	/fr/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch
-/fr/docs/Developer_Guide/Reviewer_Checklist	/fr/docs/Mozilla/Developer_guide/Reviewer_Checklist
 /fr/docs/Developer_Guide/Utilisation_de_la_Machine_Virtuelle_VM	/fr/docs/Mozilla/Developer_guide/Utilisation_de_la_Machine_Virtuelle_VM
-/fr/docs/Developer_Guide/Vous_venez_juste_de_compiler_Firefox	/fr/docs/Mozilla/Developer_guide/So_you_just_built_Firefox
 /fr/docs/DragDrop	/fr/docs/Web/API/HTML_Drag_and_Drop_API
 /fr/docs/Du_DHTML_accessible	/fr/docs/Web/Accessibility/ARIA
 /fr/docs/Décoder_encoder_en_base64	/fr/docs/Glossary/Base64
 /fr/docs/Développement_Web	/fr/docs/conflicting/Web/Guide
 /fr/docs/Développement_Web/Développer_des_sites_à_compatibilité_descendante	/fr/docs/Web/Guide/Writing_forward-compatible_websites
 /fr/docs/Développement_Web/Introduction_au_développement_web	/fr/docs/Web/Guide/Introduction_to_Web_development
-/fr/docs/Développement_de_Mozilla	/fr/docs/Mozilla/Developer_guide
 /fr/docs/ECMAScript	/fr/docs/Web/JavaScript/Language_Resources
 /fr/docs/EXSLT	/fr/docs/Web/EXSLT
 /fr/docs/EXSLT/exsl	/fr/docs/Web/EXSLT/exsl
@@ -1890,7 +1884,6 @@
 /fr/docs/Guide_JavaScript_1.5:Traitement_de_XML_avec_E4X	/fr/docs/JavaScript_Guide/Traitement_de_XML_avec_E4X
 /fr/docs/Guide_JavaScript_1.5:Travailler_avec_les_expressions_rationnelles:Exemples_d'expressions_rationnelles	/fr/docs/Web/JavaScript/Guide/Regular_Expressions
 /fr/docs/Guide_JavaScript_1.5:À_propos	/fr/docs/conflicting/Web/JavaScript/Guide/Introduction
-/fr/docs/Guide_de_développement	/fr/docs/Mozilla/Developer_guide
 /fr/docs/HTML	/fr/docs/Web/HTML
 /fr/docs/HTML/Attributes	/fr/docs/Web/HTML/Attributes
 /fr/docs/HTML/Attributs	/fr/docs/Web/HTML/Attributes
@@ -2138,7 +2131,6 @@
 /fr/docs/IndexedDB/Browser_storage_limits_and_eviction_criteria	/fr/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria
 /fr/docs/IndexedDB/Concepts_basiques_IndexedDB	/fr/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
 /fr/docs/IndexedDB/Using_IndexedDB	/fr/docs/Web/API/IndexedDB_API/Using_IndexedDB
-/fr/docs/Introduction_(alternative)	/fr/docs/Mozilla/Developer_guide/Introduction
 /fr/docs/Introduction_à_SVG_dans_HTML	/fr/docs/Web/SVG/Tutorial/SVG_In_HTML_Introduction
 /fr/docs/Introduction_à_XML	/fr/docs/Web/XML/XML_introduction
 /fr/docs/Introduction_à_XML/xml:base	/fr/docs/Web/XML/xml:base
@@ -3209,7 +3201,6 @@
 /fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/elements_menu_contextuel	/fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/Context_menu_items
 /fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/pages_web_incluses	/fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/Extension_pages
 /fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/panneaux_devtools	/fr/docs/Mozilla/Add-ons/WebExtensions/user_interface/devtools_panels
-/fr/docs/Mozilla/Developer_guide/Vous_venez_juste_de_compiler_Firefox	/fr/docs/Mozilla/Developer_guide/So_you_just_built_Firefox
 /fr/docs/Mozilla/Firefox/Versions	/fr/docs/Mozilla/Firefox/Releases
 /fr/docs/Mozilla/Firefox/Versions/1.5	/fr/docs/Mozilla/Firefox/Releases/1.5
 /fr/docs/Mozilla/Firefox/Versions/11	/fr/docs/Mozilla/Firefox/Releases/11
@@ -5946,7 +5937,6 @@
 /fr/docs/inset-block-start	/fr/docs/Web/CSS/inset-block-start
 /fr/docs/inset-inline-end	/fr/docs/Web/CSS/inset-inline-end
 /fr/docs/inset-inline-start	/fr/docs/Web/CSS/inset-inline-start
-/fr/docs/mozilla-central	/fr/docs/Mozilla/Developer_guide/mozilla-central
 /fr/docs/nsIAccessibleProvider	/fr/docs/XPCOM_Interface_Reference/nsIAccessibleProvider
 /fr/docs/nsIIdleService	/fr/docs/XPCOM_Interface_Reference/nsIIdleService
 /fr/docs/nsISupports	/fr/docs/XPCOM_Interface_Reference/nsISupports
diff --git a/files/fr/_wikihistory.json b/files/fr/_wikihistory.json
index 1ad0973926..ea36ad3564 100644
--- a/files/fr/_wikihistory.json
+++ b/files/fr/_wikihistory.json
@@ -9928,72 +9928,6 @@
       "hellosct1"
     ]
   },
-  "Mozilla/Developer_guide": {
-    "modified": "2020-08-31T05:54:42.010Z",
-    "contributors": [
-      "Voulto",
-      "chrisdavidmills",
-      "jp.jeaphil",
-      "echaudron",
-      "Jonathanlempereur",
-      "wakka27",
-      "Delapouite",
-      "bskari"
-    ]
-  },
-  "Mozilla/Developer_guide/Build_Instructions": {
-    "modified": "2019-03-23T23:48:28.119Z",
-    "contributors": [
-      "fscholz",
-      "capgemini-ocs",
-      "teoli",
-      "The RedBurn",
-      "BenoitL",
-      "Mgjbot"
-    ]
-  },
-  "Mozilla/Developer_guide/How_to_Submit_a_Patch": {
-    "modified": "2019-03-23T22:06:44.874Z",
-    "contributors": [
-      "sylvestre",
-      "chrisdavidmills",
-      "loella16",
-      "KurtC0ba1n"
-    ]
-  },
-  "Mozilla/Developer_guide/Introduction": {
-    "modified": "2019-03-23T23:40:01.462Z",
-    "contributors": [
-      "m-r-r",
-      "FredB"
-    ]
-  },
-  "Mozilla/Developer_guide/Reviewer_Checklist": {
-    "modified": "2020-04-06T15:56:36.678Z",
-    "contributors": [
-      "olivierdupon",
-      "chrisdavidmills",
-      "loella16",
-      "CarlosAvim"
-    ]
-  },
-  "Mozilla/Developer_guide/So_you_just_built_Firefox": {
-    "modified": "2019-03-23T23:19:14.291Z",
-    "contributors": [
-      "chrisdavidmills",
-      "juleschz"
-    ]
-  },
-  "Mozilla/Developer_guide/mozilla-central": {
-    "modified": "2019-03-24T00:02:46.954Z",
-    "contributors": [
-      "chrisdavidmills",
-      "QuentinAmelot",
-      "tregagnon",
-      "fscholz",
-      "BenoitL"
-    ]
-  },
   "Mozilla/Firefox": {
     "modified": "2020-01-18T13:29:35.316Z",
     "contributors": [
diff --git a/files/fr/mozilla/developer_guide/build_instructions/index.html b/files/fr/mozilla/developer_guide/build_instructions/index.html
deleted file mode 100644
index 68b753dce4..0000000000
--- a/files/fr/mozilla/developer_guide/build_instructions/index.html
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Compilation et installation
-slug: Mozilla/Developer_guide/Build_Instructions
-tags:
-  - Documentation_sur_la_compilation
-  - Développement_de_Mozilla
-translation_of: Mozilla/Developer_guide/Build_Instructions
-translation_of_original: Build_and_Install
-original_slug: Compilation_et_installation
----
-<div class="warning">
-<p>Se réferer à la page suivante pour la compilation de Thunderbird (utilisation de l'outil Mach recommandée) : <a href="/fr/docs/Simple_Thunderbird_build">Simple Thunderbird build</a></p>
-</div>
-
-<div class="note">
-<p>Ne commencez pas à compiler sans <a href='\"fr/Configuration_des_options_de_compilation\"'>configurer vos options de compilation</a> au préalable !</p>
-</div>
-
-<h3 id="Compilation" name="Compilation">Compilation</h3>
-
-<p>Vous devez utiliser GNU make pour récupérer et compiler Mozilla. Aucun autre programme « make » n'est acceptable. Sous Windows, Mac OS X et Linux, utilisez « make » pour lancer GNU make ; sur la plupart des systèmes UNIX non-GNU, utilisez « gmake ».</p>
-
-<p>Une fois les sources récupérées, assurez-vous de configurer une application comme décrit sur la page <a href="fr/Configuration_des_options_de_compilation">Configuration des options de compilation</a>.</p>
-
-<p>Pour Windows, Mac OS X et GNU/Linux, assurez-vous d'être dans le répertoire principal des sources (le répertoire « mozilla »), avant d'invoquer la commande make :</p>
-
-<pre class="eval">$ make -f client.mk build
-</pre>
-
-<p>Note pour Mac OS X : le chemin vers le répertoire des sources créé à la décompression du tarball des sources ne doit pas contenir d'espaces !</p>
-
-<p>Pour la plupart des UNIX non-GNU, la commande est :</p>
-
-<pre class="eval">$ gmake -f client.mk build
-</pre>
-
-<p>Si vous désirez configurer et compiler manuellement, placez-vous (cd) dans votre répertoire objdir, lancez configure, et ensuite make/gmake. Configure récupèrera cependant toujours les options spécifiées dans votre fichier .mozconfig.</p>
-
-<h3 id="Lancement_de_votre_nouvelle_application" name="Lancement_de_votre_nouvelle_application">Lancement de votre nouvelle application</h3>
-
-<p>Il est possible d'exécuter votre nouvelle application directement depuis le répertoire dans lequel elle a été compilée. Cependant, le répertoire de compilation peut contenir des liens symboliques vers l'arbre de compilation ; vous devez passer par l'étape d'installation/packaging pour produire une application<em>standalone</em> qui peut être partagée ou déplacée.</p>
-
-<h4 id="Windows_et_Linux" name="Windows_et_Linux">Windows et Linux</h4>
-
-<p>Sur les systèmes de compilation non-Macintosh, l'application finale peut être trouvée dans<em>objdir</em> /dist/bin. Sur les plateformes POSIX (BSD, GNU/Linux, Solaris), vous devrez exécuter le fichier « mozilla » ou « firefox », pas le binaire « mozilla-bin » ou « firefox-bin ».</p>
-
-<h4 id="Mac_OS_X" name="Mac_OS_X">Mac OS X</h4>
-
-<p>Sous Macintosh, le système de compilation produit un bundle d'application dans<em>objdir</em> /dist/<em>AppName</em> .app, par exemple<em>objdir</em> /dist/Minefield.app.</p>
-
-<p><strong>Veuillez noter</strong> que lorsque vous compilez avec --enable-debug, l'application est placée dans<em>objdir</em> /dist/<em>AppName</em> Debug.app, par exemple.<em>objdir</em> /dist/MinefieldDebug.app.</p>
-
-<p>Vous pouvez exécuter l'application soit en ouvrant le bundle à partir du Finder, soit depuis la ligne de commande à l'aide de</p>
-
-<pre class="eval">$ objdir/dist/AppName[Debug].app/Contents/MacOS/appname
-</pre>
-
-<p>par exemple :</p>
-
-<pre class="eval">$ objdir/dist/MinefieldDebug.app/Contents/MacOS/firefox
-</pre>
-
-<h5 id="Construction_d.27un_.dmg_pour_une_compilation_XULRunner" name="Construction_d.27un_.dmg_pour_une_compilation_XULRunner">Construction d'un .dmg pour une compilation XULRunner</h5>
-
-<p>Ces instructions concernent la construction d'un fichier .dmg depuis une compilation Mac OS X Universal binary.</p>
-
-<ol>
- <li>Effectuez une compilation Universal Binary</li>
- <li>Créez les fichiers source chown_root.c et chown_revert.c depuis <a class="external" href="http://mxr.mozilla.org/seamonkey/source/build/macosx/permissions/chown_revert.c">mxr:chown_root.c</a> et <a class="external" href="http://mxr.mozilla.org/seamonkey/source/build/macosx/permissions/chown_revert.c">mxr:chown_revert.c</a></li>
- <li>Utilisez gcc pour compiler ces fichiers quelque part : <code>gcc -o chown_root chown_root.c</code> et <code>gcc -o chown_revert chown_revert.c</code></li>
- <li>Rendez-vous dans «objdir»/«arch»/xulrunner/installer et entrez <code>make CHOWN_ROOT=«chemin_absolu_vers_votre_root_chown» CHOWN_REVERT=«chemin_absolu_vers_votre_binaire_inverse_chown» </code></li>
-</ol>
-
-<p>Ceci devrait vous construire un binaire dans «arch»/dist.</p>
-
-<h3 id="Installation_de_votre_application" name="Installation_de_votre_application">Installation de votre application</h3>
-
-<p>Sur les plateformes POSIX, vous pouvez installer votre application dans le système en lançant<em>gmake install</em> . Cependant, ce n'est pas recommandé et il est préférable de suivre les instructions suivantes pour créer un tarball, et de décompresser ensuite ce tarball.</p>
-
-<h4 id="Pour_le_tronc_.28Firefox_3.29" name="Pour_le_tronc_.28Firefox_3.29">Pour le tronc (Firefox 3)</h4>
-
-<p>Pour les compilations du tronc, vous pouvez simplement exécuter make package dans votre répertoire objet pour créer une compilation empaquetée. Ceci créera un fichier zip ou tar.gz dans objdir/dist que vous pourrez ensuite décompresser n'importe où. Pour compiler un installeur Windows, utilisez simplement make installer dans votre répertoire objet.</p>
-
-<h4 id="Pour_la_branche_1.8__.28Firefox_2.29" name="Pour_la_branche_1.8__.28Firefox_2.29">Pour la branche 1.8 (Firefox 2)</h4>
-
-<p>Pour la plupart des applications, préparez un tarball/zip de votre application en faisant dans un répertoire spécifique à l'application :</p>
-
-<ul>
- <li>Firefox : $ make -C objdir/browser/installer</li>
- <li>Thunderbird : $ make -C objdir/mail/installer</li>
- <li>SeaMonkey : $ make -C objdir/xpinstall/packager</li>
-</ul>
-
-<p>Pour créer un installeur Windows, lancez make avec le target « installer » dans le répertoire évoqué plus haut:</p>
-
-<ul>
- <li>Firefox : $ make -C objdir/browser/installer installer</li>
- <li>Thunderbird : $ make -C objdir/mail/installer installer</li>
- <li>SeaMonkey : $ make -C objdir/xpinstall/packager installer</li>
-</ul>
-
-<p>{{ Note("Pour réaliser l\'installeur fortement compressé utilisé par Firefox et Thunderbird avec un système de compilation basé sur Cygwin, vous devrez installer quelques programmes additionnels :") }}</p>
-
-<ul>
- <li><a class="external" href="http://www.7-zip.org/">7-zip</a></li>
- <li><a class="external" href="http://upx.sourceforge.net/">UPX</a> (pour les utilisateurs de Windows : ce programme est disponible dans l'installation de <a class="external" href="http://cygwin.com/">Cygwin</a>, vous pouvez l'installer à partir de là (catégorie Utils). N'utilisez pas la version DOS, elle ne fonctionnera pas)</li>
-</ul>
-
-<p>Ces deux utilitaires doivent être accessibles depuis le PATH. De plus, la variable MOZ_INSTALLER_USE_7ZIP doit être définie dans votre environnement. Si vous utilisez le système de compilation MozillaBuild, 7-Zip et UPX seront installés automatiquement.</p>
diff --git a/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html b/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html
deleted file mode 100644
index 9586c69a11..0000000000
--- a/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: Comment soumettre un paquet correctif
-slug: Mozilla/Developer_guide/How_to_Submit_a_Patch
-translation_of: Mozilla/Developer_guide/How_to_Submit_a_Patch
----
-<div class="summary">
-<p><span class="seoSummary">Soumettre un paquet (patch) correctif, le faire vérifier et accepter par l'équipe de Mozilla nécessitent quelques étapes ; cet article vous explique comment faire.</span></p>
-</div>
-
-<p>Le processus de soumission est représenté par le diagramme ci-dessous, le tout vous étant expliqué en details à la suite.</p>
-
-<p style="text-align: center;"><img alt="Workflow of submitting a patch: Preparation | Module Ownership | Creating a patch
-| Testing | Getting Reviews | Addressing Review Comments | Committing the Patch" class="default internal" src="/@api/deki/files/3599/=submitting-patch-workflow.png" style="height: 348px; width: 267px;"></p>
-
-<h2 id="Préparation">Préparation</h2>
-
-<p>Tout changement dans le code provient d'un bogue déclaré sur <a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">bugzilla.mozilla.org</a> ; sans bogue, le code ne sera pas examiné et sans évaluation, le code ne sera pas accepté. Afin d'éviter tout doublon, <a class="link-https" href="https://bugzilla.mozilla.org/query.cgi?format=specific">choisissez un bogue existant</a> (en) à traiter et s'il n'y en a aucun, <a href="https://bugzilla.mozilla.org/enter_bug.cgi">soumettez en un (en)</a>. La plupart des discussions à propos des futurs changements du code sont issues des bogues, alors assurez-vous que le rapport du bogue décrive exactement le problème à resoudre.</p>
-
-<p>Vérifiez aussi que le rapport de bogue soit classé dans la bonne section (produit et composant). Pour plus d'information, vous pouvez poser des questions aux groupes de discussions ou sur le <a href="irc://irc.mozilla.org/developers">canal IRC des développeurs (en).</a></p>
-
-<p>La personne travaillant sur un bogue se verra "assignée" à ce bogue sur bugzilla. Si quelqu'un d'autre y est déja désigné, envoyez un email a cette personne afin de vous coordonner ; sinon, laissez un message sur le bogue signalant que vous y travaillez et demandez que quelqu'un ayant les droits vous l'assigne.</p>
-
-<p>Certaines équipes attendent que les nouveaux contributeurs effectuent leur premier patch avant de les assigner à un bogue, ce qui signifie qu'un bogue reste disponible pour les autres contributeurs, pour le cas où aucun patch ne soit jamais créé. En exprimant votre interet dans le commentaire d'un bogue, quelqu'un de l'equipe devrait vous guider sur le processus qu'elle utilise.</p>
-
-<h2 id="Le_gestionnaire_du_module_(en_ownership)">Le gestionnaire du module (en : ownership)</h2>
-
-<p>Tout le code est supervisé par un <a class="internal" href="https://www.mozilla.org/en-US/about/governance/policies/module-ownership/" title="/en-US/docs/Mozilla Modules and Module Ownership">gestionnaire de module</a> (en). Cette personne est responsable de l'évaluation et de l'approbation des changements. Avant d'écrire le code, determinez qui gére le module et verifiez avec lui que les changements proposés sont acceptables. L'équipe est peut être à la recherche d'une nouvelle interface utilisateur (évaluation de l'interface), de nouvelles fonctions (évaluation de l'API), ou des tests peuvent être en cours portant sur le changement proposé.</p>
-
-<p>Si le gestionnaire du module ne vous semble pas clair, demandez aux groupes de discussion ou sur le canal IRC. Le journal de révision du fichier concerné peut aussi être utile. Par exemple, allez voir le journal de révision pour{{ Source("browser/base/content/browser.js") }}, en cliquant sur le lien "Hg Log" au dessus de <a href="http://dxr.mozilla.org/mozilla/source/">DXR</a> ou en tapant <code>hg log browser/base/content/browser.js</code>. Le message de vérification correspondant contiendra quelque chose comme "r=nickname", identifiant les éventuels évaluateurs pour le code en question.</p>
-
-<h2 id="Création_d'un_paquet_(en_patch)">Création d'un paquet (en : patch)</h2>
-
-<p>Les changements du code source de Mozilla sont presentés sous forme de paquets. C'est essentiellement un engagement au contrôle de version.</p>
-
-<p>Chaque paquet doit representer une seule correction complète, vous devez donc séparer les changements distincts en plusieurs paquets. Si votre changement se traduit par un grand paquet complexe, voyez s'il peut être décomposé en plusieurs <a href="https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/#many-small-commits">petits correctifs plus faciles a comprendre</a> (en). Cela faciliterait et fiabiliserait l'évaluation de vos changements, <a class="external" href="http://groups.google.com/group/mozilla.dev.planning/msg/2f99460f57f776ef?hl=en" title="http://groups.google.com/group/mozilla.dev.planning/msg/2f99460f57f776ef?hl=en">apprendre les évaluations rapides (en)</a> .</p>
-
-<div class="note">
-<p>Voir <a href="/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F" title="/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F">Comment générer un paquet (en) </a>pour plus d'informations sur la création de paquets optimisés pour l'évaluation. Voir aussi notre <a href="/en-US/docs/Developer_Guide/Reviewer_Checklist">liste de contrôle des évaluateurs</a> (en) pour une liste des meilleures pratiques de présentation du correctif que les évaluateurs vérifient ou exigent.</p>
-</div>
-
-<h2 id="Les_tests">Les tests</h2>
-
-<p>Tous les changements doivent être testés. Dans la plupart des cas, un <a class="internal" href="/en-US/docs/Mozilla_automated_testing" title="/en-US/docs/Mozilla automated testing">test automatique</a> (en) est requis pour tout changement dans le code.</p>
-
-<p>En attendant d'avoir un test automatisé pour tout le code, nous avons un logiciel d'analyse statique sur notre JavaScript, pour contrôler les meilleures pratques et les erreurs communes. Voir <a href="/en-US/docs/ESLint">ESLint (en)</a> pour plus d'informations.</p>
-
-<p>Assurez-vous que le changement ne cause pas de régressions en exécutant la suite de tests atomatique, en local, ou en utilisant le <a class="link-https" href="https://wiki.mozilla.org/Build:TryServer" title="https://wiki.mozilla.org/Build:TryServer">serveur de tests de Mozilla</a>. Un gestionnaire de module ou un developpeur sur IRC peut être disponible pour soumettre ces travaux à la place des personnes n'ayant pas accès au serveur de tests.</p>
-
-<h2 id="Soumission_du_paquet">Soumission du paquet</h2>
-
-<div class="note">
-<p>Assurez vous de la compatibilité de votre paquet avec les dernières versions de manière à éviter tout conflit.</p>
-</div>
-
-<pre>En tant que contributeur, vous devez utiliser Phabricator pour soumettre vos paquets. Voir le <a href="https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html">Guide d'utilisation de Phabricator</a>  (en) pour plus d'informations.</pre>
-
-<p>N'hésitez pas à poster des paquets partiels montrant les approches potentielles et demandez des retours sur ces derniers. Il est plus facile pour les autres de commenter et d'apporter des suggestions quand une question est illustrée par du code.</p>
-
-<h2 id="Getting_the_patch_reviewed" name="Getting_the_patch_reviewed">Obtention de l'évaluation</h2>
-
-<p>L'examen approfondi du code est un moyen mis en place par Mozilla dans le but d'obtenir un code de qualité. Tous les paquets doivent être vérifiés par le gestionnaire du module concerné ou l'un de ses pairs. Les paquets entrant dans plusieurs modules, changeant des API, ou comportant des modifications liées à la securité, feront l'objet d'une <a class="external" href="http://www.mozilla.org/hacking/reviewers.html">super-évaluaion</a>(en) supplémentaire.</p>
-
-<p>Pour plus d'informations à propos du processus d'évaluation, voyez la <a class="internal" href="/en-US/docs/Code_Review_FAQ" title="/en-US/docs/Code Review FAQ">FAQ dédiée à l'évaluation du code</a> (en). Si vos changements concernent l'interface graphique, allez voir "<a href="/en-US/docs/Developer_Guide/Requesting_feedback_and_ui-review_for_desktop_Firefox_front-end_changes" title="Requesting feedback and ui-review for desktop Firefox front-end changes">Les demandes de commentaires et les évaluations concernant l'interface graphique utilisateur de Firefox</a>" (en).</p>
-
-<p>Pour demander une évaluation, vous devrez fournir un ou pusieurs noms d'utilisateur: soit lors de la soumission du paquet, soit dans l'interface graphique.</p>
-
-<p>Voir la documentation <a href="https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html">Mozilla Phabricator</a> (en) pour plus de détails.</p>
-
-<p><em>Attention !:</em> si l'évaluateur n'a pas repondu au bout d'une semaine environ :</p>
-
-<ul>
- <li>Allez sur le canal <a class="link-irc" href="irc://irc.mozilla.org/developers">#developers</a> de l'IRC de Mozilla et demandez si quelqu'un a des informations sur les évaluations (en insérant le lien du bug en question sur le canal).</li>
- <li>Dans un deuxième temps, envoyez un courriel directement à l'évaluateur, demandez-lui si/quand il aura le temps d'évaluer le correctif ou qui d'autre pourrait le faire.</li>
- <li>En dernier ressort, demandez dans le groupe de discussion approprié sur <code>news.mozilla.org</code>.</li>
-</ul>
-
-<h2 id="Réponse_aux_commentaires_de_l'évaluation">Réponse aux commentaires de l'évaluation</h2>
-
-<p>Il est inhabituel qu'un correctif soit parfait dès la première fois. L'évaluateur marque "review-" et liste les problèmes rencontrés à corriger avant que le paquet puisse être accepté . Souvenez-vous que l'évaluation ne vise pas à vous décourager mais plutôt à encourager la meilleure résolution possible du bogue. Travaillez soigneusement les changements recommandés par l'évaluateur, joignez un nouveau correctif et demandez un nouvel examen.</p>
-
-<p>Parfois, un évaluateur accordera une approbation conditionnelle en marquant "review +" mais en indiquant des modifications mineures qui doivent être apportées, telles que les corrections d'orthographe ou d'indentation. Toutes les recommandation doivent être suivies, mais une nouvelle évaluation ne sera pas nécessaire. Effectuez les changements, liez la version corrigée, et cochez la case correspondante pour rendre le patch original obsolète. S'il y a une confusion à ce stade, une nouvelle évaluation devra être effectuée.</p>
-
-<p>Parfois après une évaluationi positive du correctif, mais avant sa publication, quelqu'un d'autre peut publier un changement qui entre en conflit avec le vôtre. Si la fusion est simple et non-invasive, publiez une version compatible, mais pour tout changement plus important, une évaluation supplémentaire sera nécessaire.</p>
-
-<p>Si, à un moment donné, le processus d'évaluation s'arrête pendant plus de deux semaines, consultez la section  «Attention» ci-dessus.</p>
-
-<p>Dans de nombreux projets open-source, les développeurs acceptent les correctifs inachevés, les finissent et les appliquent. Dans la philosophie de Mozilla, <strong>le vérificateur va seulement évaluer et commenter le paquet du contributeur</strong>. Si ce dernier refuse d'améliorer son correctif, le paquet restera tel quel jusqu'à ce que quelqu'un décide de s'en occuper.</p>
-
-<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">Envoi du correctif</h2>
-
-<p>Un paquet peut être envoyé après avoir été proprement corrigé.</p>
-
-<div class="note">
-<p>Compilez l'application avec le correctif, assurez-vous qu'elle s'exécute et passez la aux tests automatiques (et mentionnez que vous l'avez fait dans le bogue), et/ou envoyez au <a class="link-https" href="https://wiki.mozilla.org/Build:TryServerAsBranch" title="https://wiki.mozilla.org/Build:TryServerAsBranch">serveur de tests</a> (en) (indiquez le aussi dans le bug). L'insertion d'un correctif non testé fait perdre du temps à la personne qui doit le faire et peut mettre le feu à l'arborescense. Faites gagner du temps et des efforts à tout le monde en réalisant toutes les vérifications nécessaires.</p>
-
-<p>Assurez-vous que le patch est <a href="/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F" title="/en-US/docs/Creating_a_patch_that_can_be_checked_in">correctement formaté</a> (en) afin de rendre son contrôle aussi facile que possible.</p>
-</div>
-
-<p>Ajoutez le mot-clé <a class="link-https" href="https://bugzilla.mozilla.org/describekeywords.cgi#checkin-needed"><code>checkin-needed</code></a> au bug (ou si Bugzilla ne vous autorise pas à ajouter ce mot-clé, demandez à quelqu'un de l'ajouter). Les membres de la communauté ayant les droits recherchent regulièrement des bugs avec le mot-clé <a class="link-https" href="https://bugzilla.mozilla.org/describekeywords.cgi#checkin-needed"><code>checkin-needed</code></a> et les intègrent dans un délai d'environ un jour. Si le correctif n'est pas vérifié dans un délai raisonnable, rendez-vous sur le canal <a class="external" href="http://irc.mozilla.org/developers">#developers</a> de <a class="external" href="http://irc.mozilla.org/">irc.mozilla.org</a> (en) et demandez à quelqu'un de le vérifier en votre nom. La plupart du temps, un lien vers une exécution test passée sera requis dans le but de vérifier que le patch ne causera pas de problèmes après son envoi.</p>
-
-<p>Si vous publiez vous même, suivez les <a href="/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities" title="/en-US/docs/Developer Guide/Committing Rules and Responsibilities">Règles de publication et de responsabilité</a>.<br>
- Nous recommendons l'utilisation de <a href="https://moz-conduit.readthedocs.io/en/latest/lando-user.html">Lando</a> (en) pour que le code soit automatiquement envoyé.</p>
-
-<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">Régressions</h2>
-
-<p>Il se pourrait que votre code provoque des régressions fonctionnelles ou une baisse de performance. il y a une <a class="external" href="http://www.mozilla.org/hacking/regression-policy.html" title="http://www.mozilla.org/hacking/regression-policy.html">politique</a> rigoureuse vis-à-vis des baisses de performances en particulier, ce qui signifie que votre code peut être retiré et que vous allez devoir le retravailler pour le soumettre à nouveau. La régression signifie que les tests (que vous avez effectués avant l'envoi du correctif, n'est ce pas ?) n'étaient pas exhaustifs, alors vous allez devoir re-soumettre votre paquet ou faire un nouveau paquet pour corriger la régression, et réaliser les tests appropriés.</p>
-
-<p>Après la création de quelques correctifs, envisagez d'<a href="http://www.mozilla.org/hacking/committer/" title="http://www.mozilla.org/hacking/committer/">avoir accès au code source de Mozilla</a> (en).</p>
diff --git a/files/fr/mozilla/developer_guide/index.html b/files/fr/mozilla/developer_guide/index.html
deleted file mode 100644
index f771479c31..0000000000
--- a/files/fr/mozilla/developer_guide/index.html
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Guide du développeur
-slug: Mozilla/Developer_guide
-tags:
-  - Développement_de_Mozilla
-  - Landing
-  - Mozilla
-translation_of: Mozilla/Developer_guide
----
-<p><span class="seoSummary">Il y a de nombreuses façons de contribuer au projet Mozilla: coder, tester, améliorer les processus et les outils de développement, ou encore participer à la documentation . Ce guide fournit les informations pour vous aider à contribuer à Mozilla.</span></p>
-
-<div class="row topicpage-table">
-<div class="section">
-<h2 class="Documentation" id="Documentation">Documentation</h2>
-
-<dl>
- <dt><a href="/en-US/docs/Introduction" title="Introduction">Prise en main</a></dt>
- <dd>Un guide de démarrage pour les nouveaux contributeurs à Mozilla.</dd>
-</dl>
-
-<dl>
- <dt><a href="https://developer.mozilla.org/fr/docs/Developer_Guide/Source_Code">Travailler avec le code source de Mozilla</a></dt>
- <dd>Un aperçu du code, comment l'obtenir, et le guide du style de codage.</dd>
- <dt><a class="internal" href="/en-US/docs/Developer_Guide/Build_Instructions" title="en-US/docs/Developer_Guide/Build_Instructions">Instructions</a></dt>
- <dd>Comment développer Firefox, Thunderbird, SeaMonkey, ou les autres applications Mozilla.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Development_process_overview" title="en-US/docs/Developer Guide/Development process overview">Processus de développement</a></dt>
- <dd>Un aperçu de l'ensemble du processus de développement de Mozilla.</dd>
- <dt><a href="/en-US/docs/Mozilla/Multiple_Firefox_Profiles" title="en-US/docs/Mozilla/Multiple_Firefox_Profiles">Gérer plusieurs profils</a></dt>
- <dd>En travaillant sur des versions prélimaires de Firefox, il est souvent utile d'avoir plusieurs profils, un pour chaque canal ou pour différentes sortes de tests.</dd>
- <dt><a class="internal" href="/en-US/docs/Mozilla_automated_testing" title="en-US/docs/Mozilla automated testing">Tests automatisés</a></dt>
- <dd>Comment lancer des tests automatisés de Mozilla et en écrire de nouveaux.</dd>
- <dt><a class="internal" href="/en-US/docs/Developer_Guide/How_to_Submit_a_Patch" title="en-US/docs/Getting your patch in the tree">Soumettre un patch</a></dt>
- <dd>Après avoir écrit votre patch, il doit être vérifié. Cet article vous explique le processus d'examen et la procédure d'approbation du patch.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Getting_documentation_updated" title="en-US/docs/Developer_Guide/Getting documentation updated">Mise à jour de documentation</a></dt>
- <dd>Comment s'assurer que la documentation que vous développez est à jour.</dd>
- <dt><a class="internal" href="/en-US/docs/Mozilla_Modules_and_Module_Ownership" title="en-US/docs/Mozilla Modules and Module Ownership">Modules</a></dt>
- <dd>Cet article fournit des informations sur les modules Mozilla, quel est le rôle du propriétaires d'un module et comment les propriétaires sont sélectionnés.</dd>
- <dt><a class="internal" href="/en-US/docs/Code_snippets" title="en-US/docs/Code_snippets">Extraits de code</a></dt>
- <dd>Exemples de codes dont vous pourriez avoir besoin pour comprendre le fonctionnement de tout un tas de choses.</dd>
- <dt><a class="internal" href="/en-US/docs/Mozilla_Development_Strategies" title="en-US/docs/Mozilla Development Strategies">Stratégies de développement Mozilla</a></dt>
- <dd>Conseils pour travailler sur le projet Mozilla.</dd>
- <dt><a class="internal" href="/en-US/docs/Debugging" title="en-US/docs/Debugging">Débogage</a></dt>
- <dd>Conseils et guides pour déboguer le code Mozilla.</dd>
- <dt><a href="/en-US/docs/Performance" title="en-US/docs/Performance">Performance</a></dt>
- <dd>Guides de performances et utilitaires pour vous aider à mieux coder.</dd>
- <dt><a class="internal" href="/en-US/docs/The_Mozilla_platform" title="en-US/docs/The Mozilla platform">Platforme Mozilla</a></dt>
- <dd>Informations sur les travaux de la platforme Mozilla.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Adding_APIs_to_the_navigator_object" title="en-US/docs/Developer_Guide/Adding_APIs_to_the_navigator_object">Ajouter des APIs à l'objet navigateur</a> {{ gecko_minversion_inline("9.0") }}</dt>
- <dd>Comment étendre l'objet {{ domxref("window.navigator") }} avec des APIs supplémentaires.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Interface_Compatibility" title="en-US/docs/Developer Guide/Interface Compatibility">Compatibilité d'interface</a></dt>
- <dd>Guides pour la modification des scripts et APIs binaires dans Mozilla.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Customizing_Firefox" title="en-US/docs/Developer Guide/Customizing Firefox">Customiser Firefox</a></dt>
- <dd>Informations sur la création de versions customisées de Firefox.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Virtual_ARM_Linux_environment" title="Virtual ARM Linux environment">Virtual ARM Linux environment</a></dt>
- <dd>Comment installer un émulateur ARM faisant tourner linux pour des tests spécifiques ARM , mais pas nécessairement pour une platforme précise. Utile pour les développeurs mobiles.</dd>
- <dt><a href="/en-US/docs/Introduction/Obsolete_Build_Caveats_and_Tips" title="Obsolete Build Caveats and Tips">Conseils et mises en garde pour les versions obsolètes</a></dt>
- <dd>L'endroit où l'on trouvera des conseils utiles pour développer d'anciennes versions du code (mais pas la dernière version).</dd>
-</dl>
-</div>
-
-<div class="section">
-<h2 class="Tools" id="Outils">Outils</h2>
-
-<dl>
- <dt><a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">Bugzilla</a></dt>
- <dd>Base de données <a class="internal" href="/en-US/docs/Bugzilla" title="en-US/docs/Bugzilla">Bugzilla</a> utilisée pour le suivi de problèmes sur les projets Mozilla.</dd>
- <dt><a class="external" href="http://mxr.mozilla.org/" title="http://mxr.mozilla.org/">MXR</a></dt>
- <dd>Parcourir et rechercher le code source référentiel de Mozilla sur le web.</dd>
- <dt><a href="http://dxr.mozilla.org/">DXR</a></dt>
- <dd>Prochaine génération de recherche du code source de Mozilla. En développement actif.</dd>
- <dt><a class="external" href="http://bonsai.mozilla.org/cvsqueryform.cgi" title="http://bonsai.mozilla.org/cvsqueryform.cgi">Bonsai</a></dt>
- <dd>L'outils <a class="internal" href="/en-US/docs/Bonsai" title="en-US/docs/Bonsai">Bonsai</a> permet de savoir qui a changé un fichier dans le référentiel et quand.</dd>
- <dt><a class="internal" href="/en-US/docs/Mercurial" title="en-US/docs/Mercurial">Mercurial</a></dt>
- <dd>Le système de contrôle de version utilisé pour gérer le code source de Mozilla.</dd>
- <dt><a class="external" href="https://tbpl.mozilla.org/" title="http://tinderbox.mozilla.org/showbuilds.cgi">TBPL (Tinderbox Push Log)</a></dt>
- <dd><span class="internal">Tinderbox Push Log</span> montre le statut d'une branche de code (qu'elle compile ou pas).  A vérifier avant de récupérer du code ou en publier pour être certain que vous travaillez sur une branche active.</dd>
- <dt><a class="internal" href="/en-US/docs/Crash_reporting" title="en-US/docs/Crash reporting">Crash tracking</a></dt>
- <dd>Informations sur <a class="link-https" href="https://crash-reports.mozilla.com/reports" title="https://crash-reports.mozilla.com/reports">Socorro</a>, le système de rapport d'incidents.</dd>
- <dt><span class="external">Performance tracking: <a href="https://datazilla.mozilla.org/">Datazilla</a> and <a href="http://graphs.mozilla.org/">Graphs</a></span></dt>
- <dd>Voir les informations de performance du projet Mozilla.</dd>
- <dt><a href="/en-US/docs/Developer_Guide/Callgraph" title="en-US/docs/Developing Mozilla/Callgraph">Callgraph</a></dt>
- <dd>Un outil qui aide à réaliser l'analyse statique d'un code Mozilla en générant automatiquement un graphique Callgraph.</dd>
- <dt><a class="external" href="http://www.mozilla.org/community/developer-forums.html" title="http://www.mozilla.org/community/developer-forums.html">Forums développeurs</a></dt>
- <dd>Des listes de discussion classées par sujets où les développeurs peuvent échanger sur les problèmes relatifs au développement de Mozilla.</dd>
- <dt><a class="external" href="http://www.codefirefox.com/cheatsheet/" title="http://www.brianbondy.com/mozilla/cheatsheet/">Antisèches sur le développement de la plate-forme Mozilla</a></dt>
- <dd>Listes d'informations de Brian Bondy pour les développeurs de la plate-forme.</dd>
- <dt><a class="external" href="http://www.codefirefox.com/videos/" title="http://www.brianbondy.com/mozilla/cheatsheet/">Tutoriels vidéo sur le développement Firefox </a></dt>
- <dd>Tutoriels vidéo de Brian Bondy sur le développement de Firefox.</dd>
-</dl>
-</div>
-</div>
diff --git a/files/fr/mozilla/developer_guide/introduction/index.html b/files/fr/mozilla/developer_guide/introduction/index.html
deleted file mode 100644
index c6d222c487..0000000000
--- a/files/fr/mozilla/developer_guide/introduction/index.html
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: Introduction (alternative)
-slug: Mozilla/Developer_guide/Introduction
-translation_of: Mozilla/Developer_guide/Introduction
-translation_of_original: Introduction_(alternate)
-original_slug: Introduction_(alternative)
----
-<p>Bien que Firefox soit largement écrit en C++, il existe de très nombreuses manière de contribuer sans connaître C++.</p>
-<h2 id="FirefoxThunderbirdetc.">Firefox/Thunderbird/etc.</h2>
-<p>Malgré que Firefox (et les autres produits Mozilla qui sont construits depuis la base de code Mozilla) sont écrits en C++, il y a de nombreux composants écrits dans d'autres languages :</p>
-<ul>
- <li>La façade, et beaucoup de fonctions sont écrites en HTML, CSS et JavaScript.</li>
- <li>Le système de compilation est écrit en Make, shell et des éléments de Perl et Python.</li>
- <li>Certains composants et librairies tierces (comme jemalloc par exemple) sont écrits en C, et non pas en C++.</li>
- <li>De nombreux outils (comme les structures de tests) que nous utilisons sont écrits en Python et dans d'autres languages de haut niveau. Il y a de nombreuses choses que nous souhaiterions faire dans ce cadre mais qu'il est difficile de faire passer avant les fonctionnalités. Toutefois, nous aimerions réellement réaliser ces choses.</li>
-</ul>
-<p>Pour trouver du travail sur ces bogues, suivez le <a href="/fr/Introduction" title="fr/Introduction">guide principal</a>. Presque toutes les étapes sont identiques, y compris comment trouver des bogues adaptés pour commencer et le système d'encadrement.</p>
-<h2 id="Sites_Web">Sites Web</h2>
-<p>Mozilla possède plus d'une centaine d'outils et de sites, qui sont presque tous open-source. Nous avons un guide pour <a class="link-https" href="https://blog.mozilla.com/webdev/get-involved/" title="https://blog.mozilla.com/webdev/get-involved/">débuter avec les sites Web majeurs de Mozilla</a>, ainsi qu'une <a class="link-https" href="https://wiki.mozilla.org/Webdev:WhoWorksOnWhat" title="https://wiki.mozilla.org/Webdev:WhoWorksOnWhat">liste presque à jour des projets de développement Web</a> dans lesquels Mozilla est impliqué, et nous souhaitons améliorer cette liste bientôt. Utilisez cette liste pour trouver un projet qui vous intéresse, et savoir comment vous y impliquer.</p>
-<h2 id="Projets_Github">Projets Github</h2>
-<p>La <a class="link-https" href="https://github.com/mozilla" title="https://github.com/mozilla">page github de Mozilla</a> compte plus de 100 projets auxquels vous pouvez contribuer. Ces projets sont développés en utilisant les pratiques courantes de GitHub, donc faites votre branche et au boulot. Nous attendons vos demandes d'intégration ! Parmis ces projets, il y a beaucoup de projets à forte visibilité comme <a class="link-https" href="https://github.com/mozilla/jetpack" title="https://github.com/mozilla/jetpack">Jetpack</a>, <a class="link-https" href="https://github.com/mozilla/chromeless" title="https://github.com/mozilla/chromeless">Chromeless</a>, <a class="link-https" href="https://github.com/mozilla/f1" title="https://github.com/mozilla/f1">F1</a> et <a class="link-https" href="https://github.com/mozilla" title="https://github.com/mozilla">de nombreux autres</a><span class="external">.</span></p>
-<h2 id="Dépôts_Mercurial_de_Mozilla">Dépôts Mercurial de Mozilla</h2>
-<p>De nombreux projets Mozilla ont leur propre dépôt à <a class="link-https" href="https://hg.mozilla.org/" title="https://hg.mozilla.org/">hg.mozilla.org</a>. Cela montre la hiérarchie entre les projets de Mozilla, ainsi que ceux qui sont maintenus (tous ne le sont pas). Parmis eux, il y a des zones critiques de Mozilla comme <a class="link-https" href="https://hg.mozilla.org/automation" title="https://hg.mozilla.org/automation">QA</a>, <a class="link-https" href="https://hg.mozilla.org/build" title="https://hg.mozilla.org/build">RelEng</a>, la <a class="link-https" href="https://hg.mozilla.org/l10n" title="https://hg.mozilla.org/l10n">localisation</a>, <a class="link-https" href="https://hg.mozilla.org/webtools" title="https://hg.mozilla.org/webtools">webtools</a>, les <a class="link-https" href="https://hg.mozilla.org/users/" title="https://hg.mozilla.org/users/">dépôts des développeurs majeurs</a>, et <a class="link-https" href="https://hg.mozilla.org" title="https://hg.mozilla.org/">plus</a>.</p>
-<h2 id="D'autres_manières_de_s'engager">D'autres manières de s'engager</h2>
-<p>Il existe beaucoup d'autres manières de contribuer à la mission de Mozilla sans programmer. Si vous souhaitez vous diriger vers le design, l'aide, la traduction, les tests ou d'autres types de contributions, rendez vous sur la <a class="link-https" href="https://www.mozilla.org/contribute/areas.html" title="https://www.mozilla.org/contribute/areas.html">page dédiées au volontariat</a>.</p>
diff --git a/files/fr/mozilla/developer_guide/mozilla-central/index.html b/files/fr/mozilla/developer_guide/mozilla-central/index.html
deleted file mode 100644
index ea566ea8e1..0000000000
--- a/files/fr/mozilla/developer_guide/mozilla-central/index.html
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: mozilla-central
-slug: Mozilla/Developer_guide/mozilla-central
-tags:
-  - Développement_de_Mozilla
-  - Mercurial
-translation_of: Mozilla/Developer_guide/mozilla-central
----
-<p><strong><code>mozilla-central</code></strong> est un dépôt <a href="/fr/Mercurial" title="fr/Mercurial">Mercurial</a> du code de Mozilla : <a class="external" href="http://hg.mozilla.org/mozilla-central" rel="freelink">http://hg.mozilla.org/mozilla-central</a> . Il s'agit d'un point d'intégration stable pour les changements qui seront incorporés dans la base de code de Mozilla 2.</p>
-
-<p>La page de <a href="/fr/Tinderbox" title="fr/Tinderbox">Tinderbox</a> pour mozilla-central se trouve à <a class="external" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla2" rel="freelink">http://tinderbox.mozilla.org/showbui...?tree=Mozilla2</a> .</p>
-
-<p>{{ Note("contrairement au dépôt CVS de Mozilla, seules les sources de Firefox et XULRunner font partie de mozilla-central. Des dépôts séparés sont utilisés pour d\'autres applications et projets.") }}</p>
-
-<h3 id="R.C3.A8gles_pour_l.27arbre_mozilla-central" name="R.C3.A8gles_pour_l.27arbre_mozilla-central">Règles pour l'arbre mozilla-central</h3>
-
-<p>La base de code mozilla-central doit être stable sur les <a href="/fr/Configurations_de_compilation_gérées" title="fr/Configurations_de_compilation_gérées">plateformes principales</a> à tout moment :</p>
-
-<ul>
- <li>Les tests unitaires automatisés doivent être passés</li>
- <li>Les tests automatisés de performances et les tests de fuites ne doivent pas régresser</li>
- <li>Toute régression fera l'objet d'un retrait immédiat du patch incriminé</li>
- <li>Les développeurs ne doivent <em>pas</em> essayer de publier leurs changements dans mozilla-central pour vérifier si un patch fait régresser des tests de performances ou des tests unitaires. C'est le {{ interwiki('wikimo', 'Build:TryServer', 'serveur de test') }} qui doit être utilisé pour cela.</li>
-</ul>
-
-<h4 id="Changements_dans_les_API" name="Changements_dans_les_API">Changements dans les API</h4>
-
-<p>En préparation de Mozilla 1.9.1, les règles suivantes sont à respecter pour les changements dans les API :</p>
-
-<ul>
- <li>les changements des API <strong>gelées</strong> (<em>frozen</em>) ne sont pas permis.</li>
- <li>les changements des API <strong>non gelées</strong> doivent être mûrement réfléchis.
-  <ul>
-   <li>Tout impact sur les extensions JS doit être évité ou minimisé et soigneusement <a href="/Fr/Firefox_3.5_pour_les_développeurs" title="fr/Firefox_3.1_pour_les_développeurs">documenté</a>.</li>
-   <li>Les vérificateurs (<em>reviewers</em>) doivent explicitement approuver les changements d'API le cas échéant.</li>
-   <li>En cas de doute, posez la question sur les groupes de discussion mozilla.dev.platform ou mozilla.dev.apps.firefox.</li>
-  </ul>
- </li>
-</ul>
-
-<p>Ces règles changeront après le branchement de la version 1.9.1.</p>
-
-<h3 id="Soumission_de_modifications_sur_mozilla-central" name="Soumission_de_modifications_sur_mozilla-central">Soumission de modifications sur mozilla-central</h3>
-
-<p>Tous les développeurs qui ont un accès en écriture sur le CVS doivent avoir reçu un e-mail avec les détails d'identification LDAP nécessaires pour effectuer un <em>push</em> sur hg.mozilla.org. Si vous pensez quie vous devriez y avoir accès mais ne connaissez pas vos détails d'identification, <a class="link-https" href="https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&amp;component=Server+Operations:+Account+Requests">ouvrez un bug</a>. Vous pouvez utiliser la commande <code>hg push</code> pour soumettre des changements (<em>changesets</em>) au serveur.</p>
-
-<ul>
- <li>Les modifications ne doivent pas faire apparaître plusieurs répertoires de base (<em>heads</em>) dans mozilla-central</li>
- <li>Essayez de minimiser l'historique. Une soumission unique ou quelques changesets indépendants sont préférables à de nombreux changesets « travaux en cours » qui encombreront l'historique. Pensez à utiliser des <a href="/fr/Files_Mercurial" title="fr/Files_Mercurial">files Mercurial</a> pour gérer vos patchs avant la soumission.</li>
- <li>Au moins pour la soumission du dernier changeset, le numéro de bug et le vérificateur (<em>reviewer</em>) pour la modification doivent être mentionnés.</li>
- <li>Les modifications doivent être soumises à <code><a class="external" href="ssh://hg.mozilla.org/mozilla-central/" rel="freelink">ssh://hg.mozilla.org/mozilla-central/</a></code>, consultez <a href="http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html" title="Mercurial for Mozillians">Le guide Mercurial for Mozillians (en anglais)</a> pour plus de détails sur la mise en place de votre configuration.</li>
-</ul>
-
-<p> </p>
-
-<p>Les copies de <a class="internal" href="/fr/Extraits_CVS_externes_dans_mozilla-central" title="fr/Extraits CVS externes dans mozilla-central">NSPR et NSS dans mozilla-central</a> sont soumises à certaines règles particulières.</p>
-
-<h3 id="Voir_.C3.A9galement" name="Voir_.C3.A9galement">Voir également</h3>
-
-<ul>
- <li>Le billet <a class="external" href="http://developer.mozilla.org/devnews/index.php/2008/06/02/mozilla-central-open-for-business/">mozilla-central: open for business</a> de devnews.</li>
- <li>Sur Bugzilla, <a class="link-https" href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=433384&amp;hide_resolved=1">le relevé des problèmes rendant le développement difficile sur mozilla-central</a></li>
-</ul>
-
-<p>{{ languages( { "en": "en/Mozilla-central", "es": "es/Mozilla-central", "ja": "ja/Mozilla-central" } ) }}</p>
diff --git a/files/fr/mozilla/developer_guide/reviewer_checklist/index.html b/files/fr/mozilla/developer_guide/reviewer_checklist/index.html
deleted file mode 100644
index 7b5675a62f..0000000000
--- a/files/fr/mozilla/developer_guide/reviewer_checklist/index.html
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: Liste de contrôle de l'évaluateur
-slug: Mozilla/Developer_guide/Reviewer_Checklist
-tags:
-  - Correction
-  - Evaluation
-  - Guide
-translation_of: Mozilla/Developer_guide/Reviewer_Checklist
----
-<div class="summary">
-<p>Soumettre des correctifs pour le code source de Mozilla n’a pas besoin d’être complexe. Cet article fournit une liste des meilleures pratiques, à suivre pour votre mise-à-jour, que les évaluateurs vérifient ou exigent. Suivre ces recommandations mène à un processus d'évaluation et d’acception plus doux et plus rapide.<span class="seoSummary">.</span></p>
-</div>
-
-<h2 id="Bonne_citoyenneté_sur_le_web">Bonne citoyenneté sur le web</h2>
-
-<ul>
- <li>Assurez-vous que les nouvelles API développées pour le Web ont un sens et que les normes sont suivies ou pré-testées par défaut.</li>
- <li>En C++, utilisez le wrapper-cache si besoin. Si votre projet peut être récupéré ailleurs, sans création dans le processus, il doit être mis en cache (wrapper-cache).</li>
-</ul>
-
-<h2 id="Correction">Correction</h2>
-
-<ul>
- <li>Le bogue qui est en train d’être corrigé est un bogue valide et a besoin d’être corrigé.</li>
- <li>Le correctif (patch) apporté règle le problème.</li>
- <li>Le correctif n’est pas inutilement compliqué.</li>
- <li>Le correctif n'ajoute pas de duplications du code existant (les doublons pourraient signifier qu'il est nécessaire de refactoriser). Généralement, cela dépend d'une "partie 0" d'un bug, qui est "une chose ordonnée pour rendre le correctif plus facile à écrire et à réviser".</li>
- <li>Si la qualité du correctif doit être vérifiée, vous devrez fournir les étapes pour le reproduire (STR – Steps To Reproduce).</li>
-</ul>
-
-<h2 id="Qualité">Qualité</h2>
-
-<ul>
- <li>Si vous pouvez le tester par unité, vous devriez le faire.</li>
- <li>Si c’est du JavaScript, essayez de concevoir et de construire de telle sorte que xpcshell puisse exercer la plupart des fonctionnalités. C’est plus rapide.</li>
- <li>Assurez-vous que le correctif ne crée pas de code inutilisé (par exemple : supprimez les chaînes quand une fonctionnalité est supprimée)</li>
- <li>Toutes les exceptions capturées doivent être enregistrées au bon niveau, avec les informations appropriées et identifiables. Aussi considérez le coût du traitement et de l’enregistrement des "logs" <em>(journaux)</em>. [Astuce : Vérifier les niveaux de log est couteux sauf si vous utilisez Logger.]</li>
-</ul>
-
-<h2 id="Style">Style</h2>
-
-<ul>
- <li>Suivez <a href="/fr/docs/Developer_Guide/Coding_Style">le guide de style</a> pour le langage et le module concerné.</li>
- <li>Suivez le style local pour le code environnant, même si le style local n’est pas documenté de façon formelle.</li>
- <li>Les nouveaux fichiers ont des déclarations de licence et des modèles.</li>
- <li>Les nouveaux fichiers JavaScript doivent utiliser un mode strict.</li>
- <li>Espace blanc en queue (git diff et splinter view surlignent ces espaces, il en est de même pour hg avec l’extension de couleur activé). Les espaces blancs peuvent être facilement corrigés en Mercurial en utilisant <a href="http://mercurial.selenic.com/wiki/CheckFilesExtension">l’extension CheckFiles</a>. Dans git, vous pouvez utiliser git rebase --whitespace=fix.</li>
-</ul>
-
-<h2 id="Problèmes_de_sécurité">Problèmes de sécurité</h2>
-
-<ul>
- <li>Il ne devrait pas y avoir d’écriture dans des fichiers arbitraires en dehors du dossier de profil.</li>
- <li>Soyez prudent quand vous lisez des entrées clavier d’utilisateur, des données réseaux ou fichiers provenant du disque. Partez du postulat que les entrées sont trop volumineuses, trop courtes, vides, malformées ou malicieuses.</li>
- <li>Une marque (tag) comme contrôle de sécurité n’est pas sûr.</li>
- <li>Si vous écrivez du code qui utilise JSAPI, il y a de grandes chances que vous soyez sur la mauvaise voie. Essayez d’éviter ça.</li>
-</ul>
-
-<h2 id="Problèmes_de_confidentialité">Problèmes de confidentialité</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Il ne devrait pas y avoir de journalisation d'URL ou de contenu dont les URL peuvent être déduites.</span></span></li>
- <li>[Fennec : Android Services <span id="result_box" lang="fr"><span>a "Logger.pii ()" à cette fin (par exemple, journal de profil)].</span></span></li>
- <li>Marquage pour l'évaluation de la confidentialité si nécessaire.</li>
-</ul>
-
-<h2 id="Fuite_de_ressources">Fuite de ressources</h2>
-
-<ul>
- <li>En Java, les fuites de mémoire sont en grande partie dues aux exploitations singulières des caches et des collections, ou aux observateurs collés autour, ou aux exécutables assis sur une file d'attente.</li>
- <li>En C++, utiliser cycle-collect selon les besoins. Si JavaScript peut voir votre objet, il a probablement besoin d'une collecte cyclique.</li>
- <li>[Fennec : <span id="result_box" lang="fr"><span>Si votre vue personnalisée fait des animations, il est préférable de nettoyer les exécutables dans</span></span> onDetachFromWindow().]</li>
- <li><span id="result_box" lang="fr"><span>Assurez-vous que toutes les poignées de fichiers et autres ressources disponibles sont fermées de manière appropriée.</span></span></li>
- <li>[Fennec : <span id="result_box" lang="fr"><span>Lorsque vous écrivez des tests qui utilisent PaintedSurface, assurez-vous que PaintedSurface est fermé lorsque vous avez terminé.</span></span> ]</li>
-</ul>
-
-<h2 id="Impact_sur_les_performances">Impact sur les performances</h2>
-
-<ul>
- <li>Contrôlez votre fil principal IO <em>(entrée-sortie)</em> [Fennec : Android <span class="short_text" id="result_box" lang="fr"><span>peut avertir à propos de cela avec "strictmode"</span></span> ].</li>
- <li><span id="result_box" lang="fr"><span>Supprimez le journal de débogage qui n'est pas nécessaire dans la production.</span></span></li>
-</ul>
-
-<h2 id="Problèmes_de_fil">Problèmes de fil</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Enorme : utilisation correcte du verrouillage et de la volatilité;</span> "<span>livelock" <em>(ouverture)</em> et "deadlock" <em>(blocage)</em>;</span> "ownership" <em>(possession</em>)<span>.</span></span></li>
- <li>[Fennec: <span id="result_box" lang="fr"><span>Toutes les méthodes de visualisation ne doivent être touchées que par un fil de l'interface utilisateur</span></span> .]</li>
- <li>[Fennec: <span id="result_box" lang="fr"><span>Sensibilisation au cycle de vie de l'activité (fonctionne avec "ne jamais garder les activités").</span> <span>Testez également avec oom-fennec</span></span> (<a href="https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/%29">https://hg.mozilla.org/users/blassey_mozilla.com/oom-fennec/)</a>].</li>
-</ul>
-
-<h2 id="Compatibilité">Compatibilité</h2>
-
-<ul>
- <li>Fichiers de version, bases de données, messages.</li>
- <li><span id="result_box" lang="fr"><span>Étiqueter les messages avec des identifiants pour des appelants sans ambiguité.</span></span></li>
- <li>IDL UUIDs <span id="result_box" lang="fr"><span>sont mis à jour en même temps que l'interface</span></span> .</li>
- <li>Les permissions Android <span id="result_box" lang="fr"><span>devraient être "gouped" <em>(regroupées)</em> dans une version commune pour éviter de casser les mises à jour automatiques</span></span> .</li>
- <li>Les API Android ajoutées à partir de Froyo devraient être surveillées par un contrôle de version.</li>
-</ul>
-
-<h2 id="Préférences">Préférences</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Si la fonctionnalité utilisée est couverte par les préférences, assurez-vous du branchement.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Si vous travaillez sur une nouvelle fonctionnalité, envisagez d'ajouter des préférences pour contrôler le comportement</span></span> .</li>
- <li><span id="result_box" lang="fr"><span>Envisagez d'ajouter des preférences pour désactiver complètement la fonctionnalité dans le cas où des bogues se retrouvent plus tard dans le cycle de libération.</span></span></li>
- <li>[Fennec: <span id="result_box" lang="fr"><span>"Prefs" peuvent être les préférences Gecko prefs, les valeurs de "SharedPreferences" ou "build-time flags".</span> <span>Celui que vous devez choisir dépend de la façon dont la fonctionnalité est implémentée : un service Java pur ne peut pas facilement vérifier Gecko prefs, par exemple.</span></span>]</li>
-</ul>
-
-<h2 id="Chaînes_de_caractères">Chaînes de caractères</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Il ne devrait pas y avoir de changements de chaîne dans les correctifs (y compris les extractions de chaînes)</span></span>.</li>
- <li><span id="result_box" lang="fr"><span>Nom des entités Rev pour les changements de chaîne.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Lorsque vous modifiez l'interface utilisateur, soyez conscient du fait que les chaînes auront différentes longueurs dans différentes régions.</span></span></li>
-</ul>
-
-<h2 id="Documentation">Documentation</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Le message de présentation doit décrire ce que le patch change (ne pas être une copie du résumé des bogues).</span> <span>La première ligne devrait être une description courte (puisque seule la première ligne est affichée dans le journal), et une description supplémentaire, si nécessaire, devrait être présente, correctement développée, dans des lignes ultérieures.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Des morceaux potentiellement confus de code sont suffisamment documentés.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Signaler un bug avec "dev-doc-needed" si des ajouts (addon) ou des API Web sont affectés.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Utilisez Javadocs de manière exhaustive, en particulier sur toutes les nouvelles méthodes non privées.</span></span></li>
- <li><span id="result_box" lang="fr"><span>Lorsque vous déplacez des fichiers, assurez-vous que la responsabilité / l'annotation est préservée.</span></span></li>
-</ul>
-
-<h2 id="Accessibilité">Accessibilité</h2>
-
-<ul>
- <li><span id="result_box" lang="fr"><span>Pour les pages HTML, les images devraient avoir l'attribut "alt" défini le cas échéant.</span> <span>De même, un bouton qui n'est pas un bouton HTML natif devrait avoir un rôle = "button" <em>(bouton)</em> et l'ensemble d'attributs d'étiquette aria.</span></span></li>
- <li>[Fennec: <span id="result_box" lang="fr"><span>Assurez-vous que la </span></span> contentDescription <em>(description du contenu)</em><span lang="fr"><span> est définie pour les parties de l'interface utilisateur qui devraient être accessibles</span></span>].</li>
-</ul>
diff --git a/files/fr/mozilla/developer_guide/so_you_just_built_firefox/index.html b/files/fr/mozilla/developer_guide/so_you_just_built_firefox/index.html
deleted file mode 100644
index 454d0a043e..0000000000
--- a/files/fr/mozilla/developer_guide/so_you_just_built_firefox/index.html
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Vous venez juste de compiler Firefox
-slug: Mozilla/Developer_guide/So_you_just_built_Firefox
-translation_of: Mozilla/Developer_guide/So_you_just_built_Firefox
-original_slug: Mozilla/Developer_guide/Vous_venez_juste_de_compiler_Firefox
----
-<p>Un lien vers cette page sera affiché après que vous ayez compilé Firefox, avec succès. Elle contient des informations sur les étapes à suivre, avec des liens pour lancer les tests, packager votre executable, etc. Pour le contenu, essayez d'être bref, et d'afficher des liens vers les pages que vous pensez utiles. Votre audience est composée de personnes qui viennent de compiler Firefox, pour la première fois.</p>
-<p>Voici quelques liens qui pourraient vous servir :</p>
-<p><a href="/en/Running_automated_tests" title="Running automated tests">Lancer les tests</a></p>
-<p><a href="/En/Debugging" title="Debugging">Debugger</a></p>
-<p><a href="/en/Bug_writing_guidelines" title="Bug writing guidelines">Rapporter un bug</a></p>