Fix: typos

README.md

@@ -4,7 +4,7 @@ Bienvenue dans la documentation française officielle de Solidity! Veuillez note
 
 ## Documentation
 
-Dès que toutes les traductions seront terminées, le Français sera ajouté au menu déroulant de la documenttation officiel et le contenu de ce référentiel sera disponible pour consultation. 
+Dès que toutes les traductions seront terminées, le Français sera ajouté au menu déroulant de la documentation officielle et le contenu de ce référentiel sera disponible pour consultation. 
 Cependant, jusque-là, la traduction française sera temporairement disponible sur **https://fr-solidity.readthedocs.io/fr/latest/**.
 
 ## Modérateur et Contributeur
@@ -22,14 +22,14 @@ Avant de contribuer, lisez le glossaire et le guide de style (liens ici s'ils ex
 
 Soyez rapide avec vos traductions ! Si vous constatez que vous ne pouvez plus vous engager, faites-le savoir aux responsables afin qu'ils puissent attribuer la page à quelqu'un d'autre.
 
-> Quiconque souhaite contribuer à la documentation officiel Solidity French est libre de participer.
+> Quiconque souhaite contribuer à la documentation officielle Solidity French est libre de participer.
 
 ## Règles de traduction
 
 Lors de la traduction, veuillez suivre ces règles :
 
 1. Ne modifiez jamais le nom ou le chemin du fichier.
-2. Pour les noms propres ou le vocabulaire conceptuel important à Solidity, traduisez phonétiquement ou laisser comme telle (par exemple, Smart Contract peu se traduire par "contrat intelligent").
+2. Pour les noms propres ou le vocabulaire conceptuel important à Solidity, traduisez phonétiquement ou laisser comme telle (par exemple, Smart Contract peut se traduire par "contrat intelligent").
 3. Utilisez une police honorifique et soutenu.
 4. Le code tels que les noms de variables ne doivent pas être transcrites. Cependant, les commentaires sont traduits en Français.
 

docs/analysing-compilation-output.rst

@@ -6,7 +6,7 @@ Analyse de la sortie du compilateur
 
 Il est souvent utile d'examiner le code d'assemblage généré par le compilateur. Le binaire généré,
 c'est-à-dire la sortie de ``solc --bin contract.sol``, est généralement difficile à lire. Il est recommandé
-d'utiliser l'indicateur ``--asm`` pour analyser la sortie de l'assemblage. Même pour les gros contrats, regarder une
+d'utiliser l'indicateur ``--asm`` pour analyser la sortie de l'assemblage. Même pour les gros contrats, regarder un
 visuel de l'assemblage avant et après un changement est souvent très instructif.
 
 Considérons le contrat suivant (nommé, disons ``contract.sol``) :

docs/common-patterns.rst

@@ -12,9 +12,8 @@ Retrait des contrats
 
 La méthode recommandée pour envoyer des fonds après un effet
 est d'utiliser le modèle de retrait. Bien que la méthode la plus intuitive
-la méthode la plus intuitive pour envoyer de l'Ether, suite à un effet,
-est un appel direct de "transfert", ce n'est pas recommandé car il introduit un
-car elle introduit un risque potentiel de sécurité. Vous pouvez lire
+pour envoyer de l'Ether suite à un effet, est un appel direct de "transfert", 
+ce n'est pas recommandé car cela introduit un risque potentiel de sécurité. Vous pouvez lire
 plus d'informations à ce sujet sur la page :ref:`security_considerations`.
 
 Voici un exemple du schéma de retrait en pratique dans

docs/contributing.rst

@@ -58,7 +58,7 @@ Pour contribuer, merci de vous détacher de la branche ``develop`` et d'y faire
 Vos messages de commit doivent détailler *pourquoi* vous avez fait votre changement
 en plus de *ce que vous avez fait (sauf si c'est un changement minuscule)*.
 
-Si vous avez besoin de retirer des changements de la branche ``develop`` après avoir fait votre fork (par
+Si vous avez besoin de retirer des changements de la branche ``develop`` après avoir fait votre fork 
 (par exemple, pour résoudre des conflits de fusion potentiels), évitez d'utiliser ``git merge``
 et à la place, ``git rebase`` votre branche. Cela nous aidera à revoir votre changement
 plus facilement.

docs/control-structures.rst

@@ -53,7 +53,7 @@ cet exemple absurde :
     }
 
 Ces appels de fonction sont traduits en simples sauts à l'intérieur de l'EVM. Cela a pour
-l'effet que la mémoire courante n'est pas effacée, c'est-à-dire que le passage des références de mémoire
+effet que la mémoire courante n'est pas effacée, c'est-à-dire que le passage des références de mémoire
 aux fonctions appelées en interne est très efficace. Seules les fonctions de la même
 instance de contrat peuvent être appelées en interne.
 
@@ -146,8 +146,8 @@ lève une exception ou tombe en panne.
     afin que votre contrat ne soit pas vulnérable à un exploit de réentraînement.
 
 .. note::
-    Avant Solidity 0.6.2, la manière recommandée de spécifier la valeur et le gaz était de
-    utiliser "f.value(x).gas(g)()``. Cette méthode a été dépréciée dans Solidity 0.6.2 et n'est
+    Avant Solidity 0.6.2, la manière recommandée de spécifier la valeur et le gaz était d'utiliser 
+    "f.value(x).gas(g)()``. Cette méthode a été dépréciée dans Solidity 0.6.2 et n'est
     plus possible depuis Solidity 0.7.0.
 
 Appels nominatifs et paramètres de fonctions anonymes