fixed french typo for lesson 5 (CryptozombiesHQ#428)

fixed french typo for lesson 5

fr/5/00-overview.md

@@ -10,4 +10,4 @@ Dans cette leçon, nous allons apprendre des choses un peu plus complexes.
 
 Nous allons parler des **jetons (tokens)**, du standard **ERC721**, et des **actifs crypto-collectibles**.
 
-En d'autres terme, nous allons **faire en sorte que vous puissiez échanger vos zombies avec vos amis.**
+En d'autres termes, nous allons **faire en sorte que vous puissiez échanger vos zombies avec vos amis.**

fr/5/01-erc721-1.md

@@ -246,9 +246,9 @@ Commençons par les **_tokens_**.
 
 Si vous êtes dans la sphère Ethereum depuis un moment, vous avez sûrement entendu parler des tokens - en particulier des **tokens ERC20**.
 
-un **_token_** Ethereum est un smart contract qui suit un ensemble de règles - à savoir, il implémente un ensemble de fonctions standards que tous les autres contrats de token partagent, comme `transfer(address _to, uint256 _value)` et `balanceOf(address _owner)`.
+un **_token_** Ethereum est un smart contract qui suit un ensemble de règles - à savoir, il implémente un ensemble de fonctions standards que tous les autres contrats de tokens partagent, comme `transfer(address _to, uint256 _value)` et `balanceOf(address _owner)`.
 
-Le smart contract a habituellement un mappage interne, `mapping(address => uint256) balances`, qui permet de connaître la balance de chaque adresse.
+Le smart contract a habituellement un mappage interne, `mapping(address => uint256) balances`, qui permet de connaître le solde de chaque adresse.
 
 Un token est simplement un contrat qui permet de connaître combien de ce token chaque personne possède, et qui a certaines fonctions pour permettre aux utilisateurs de transférer leurs tokens à d'autres adresses.
 
@@ -260,21 +260,21 @@ Cela veut dire que si vous construisez une application qui est capable d'interag
 
 On pourrait prendre comme exemple un échange. Quand un échange ajoute un nouveau token ERC20, en vérité il a juste besoin d'ajouter un nouveau smart contract. Les utilisateurs pourront utiliser ce contrat pour envoyer des tokens sur l'adresse de l'échange, et l'échange pourra utiliser ce contrat pour renvoyer des tokens aux utilisateurs quand ils voudront retirer.
 
-L'échange a simplement besoin d'implémenter une fois la logique de transfert, et quand il veut ajouter un nouveau token ERC20, il suffit simplement d'ajouter l'adresse du nouveau contrat à sa base de donnée.
+L'échange a simplement besoin d'implémenter une fois la logique de transfert, et quand il veut ajouter un nouveau token ERC20, il suffit simplement d'ajouter l'adresse du nouveau contrat à sa base de données.
 
 ### Autres standards des tokens
 
-Les tokens ERC20 sont vraiment pratiques pour servir en temps que monnaies. Mais ils ne sont pas vraiment utiles pour représenter des zombies dans notre jeu de zombie.
+Les tokens ERC20 sont vraiment pratiques pour servir en temps que monnaie. Mais ils ne sont pas vraiment utiles pour représenter des zombies dans notre jeu de zombie.
 
 Premièrement, les zombies ne sont pas divisibles comme les monnaies - je peux vous envoyer 0.237 ETH, mais je ne peux pas vous envoyer 0.237 d'un zombie.
 
 Deuxièmement, tous les zombies ne sont pas égaux. Votre zombie "**Pierre**" de niveau 2 n'est pas du tout égal à mon zombie de niveau 732 "**H4XF13LD MORRIS 💯💯😎💯💯**". (Tu peux pas test, *Pierre*).
 
 Il existe un autre standard de token qui est beaucoup plus adapté pour les crypto-collectibles comme CryptoZombies — ce sont les **_tokens ERC721._**
 
-Les **_tokens ERC721_** **ne** sont **pas** interchangeable puisqu'ils sont supposés être unique, et ne sont pas divisibles. Vous pouvez seulement les échanger en entier, et ils ont chacun un ID unique. C'est exactement cela que l'on veut pour rendre nos zombies échangeables.
+Les **_tokens ERC721_** **ne** sont **pas** interchangeable puisqu'ils sont supposés être uniques, et ne sont pas divisibles. Vous pouvez seulement les échanger en entier, et ils ont chacun un ID unique. C'est exactement cela que l'on veut pour rendre nos zombies échangeables.
 
-> Remarque : En utilisant un standard comme ERC721, nous n'avons pas besoin d'implémenter les logiques qui définissent comment les joueurs vont échanger / vendre les zombies. Si on respecter les spécifications, quelqu'un d'autre pourrait construire une plateforme d'échange pour les actifs crypto-échangeables, et nos zombies ERC721 seraient compatibles avec cette plateforme. C'est un avantage évident d'utiliser un standard de token au lieu d'implémenter sa propre logique d'échange.
+> Remarque : En utilisant un standard comme ERC721, nous n'avons pas besoin d'implémenter les logiques qui définissent comment les joueurs vont échanger / vendre les zombies. Si on respecte les spécifications, quelqu'un d'autre pourrait construire une plateforme d'échange pour les actifs crypto-échangeables, et nos zombies ERC721 seraient compatibles avec cette plateforme. C'est un avantage évident d'utiliser un standard de token au lieu d'implémenter sa propre logique d'échange.
 
 ## A votre tour
 

fr/5/02-erc721-2.md

@@ -285,7 +285,7 @@ Cela pourrait paraître beaucoup, mais ne vous laissez pas impressionner ! Nous
 
 ### Implémenter le contrat d'un token
 
-Quand on implémente le contrat d'un token, la première chose à faire et de copier l'interface dans son propre fichier Solidity et d'importer avec `import "./erc721.sol";`. Ensuite notre contrat doit en hériter, et nous pouvons réécrire chaque méthode avec une définition de fonction.
+Quand on implémente le contrat d'un token, la première chose à faire est de copier l'interface dans son propre fichier Solidity et d'importer avec `import "./erc721.sol";`. Ensuite notre contrat doit en hériter, et nous pouvons réécrire chaque méthode avec une définition de fonction.
 
 Mais — `ZombieOwnership` hérite déjà de `ZombieAttack` — comment pourrait-il aussi hériter de `ERC721` ?
 
@@ -303,7 +303,7 @@ Essayons.
 
 ## A votre tour
 
-Nous avons créé `erc721.sol` avec son interface en avance.
+Nous avons créé d'avance `erc721.sol` avec son interface.
 
 1. Importez `erc721.sol` dans `zombieownership.sol`
 

fr/5/03-erc721-3.md

@@ -303,7 +303,7 @@ Bien, maintenant nous pouvons nous pencher sur l'implémentation ERC721 !
 
 Nous avons pris de l'avance et avons copié la structure vide de toutes les fonctions que vous allez implémenter dans cette leçon.
 
-Dans ce chapitre, nous allons implémenter les deux premières méthodes : `balanceOf` (balance de) et `ownerOf` (propriétaire de).
+Dans ce chapitre, nous allons implémenter les deux premières méthodes : `balanceOf` (solde de) et `ownerOf` (propriétaire de).
 
 ### `balanceOf`
 
@@ -313,7 +313,7 @@ Dans ce chapitre, nous allons implémenter les deux premières méthodes : `bala
 
 Cette fonction prend simplement une `address`, et renvoie combien de tokens cette `address` possède.
 
-Dans notre cas, nos "tokens" sont des Zombies. Vous vous rappelez dans notre DApp où nous avons stocké combien de zombies un utilisateur a ?
+Dans notre cas, nos "tokens" sont des Zombies. Vous vous rappelez dans notre DApp où nous avons stocké combien de zombies un utilisateur possède ?
 
 ### `ownerOf`
 
@@ -325,13 +325,13 @@ Cette fonction prend un ID token (dans notre cas, un ID Zombie), et renvoie l'`a
 
 À nouveau, c'est une implémentation assez simple, car nous avons déjà un `mapping` dans notre DApp qui stocke cette information. Nous pouvons implémenter cette fonction simplement en une ligne, avec seulement une déclaration `return`.
 
-> Remarque : rappelez-vous, `uint256` est équivalent à `uint`. Nous utilisions `uint` dans notre code jusqu'à présent, mais nous allons utiliser `uint256` ici car nous avons simplement copier/coller depuis les spécificités.
+> Remarque : rappelez-vous, `uint256` est équivalent à `uint`. Jusqu'à présent nous utilisions `uint` dans notre code, mais ici nous allons utiliser `uint256` car nous avons simplement copié/collé depuis les spécificités.
 
 ## A votre tour
 
 Je vous laisse trouver comment implémenter ces 2 fonctions.
 
-Chaque fonction devra simplement être 1 ligne de code, une déclaration `return`. Vous pouvez regarder les codes des précédentes leçons pour voir où nous stockons ces données. Si vous ne trouver pas, vous pouvez utiliser le bouton "Montrez-moi la réponse" pour avoir de l'aide.
+Chaque fonction devra simplement être une ligne de code, une déclaration `return`. Vous pouvez regarder les codes des précédentes leçons pour voir où nous stockons ces données. Si vous ne trouvez pas, vous pouvez utiliser le bouton "Montrez-moi la réponse" pour avoir de l'aide.
 
 1. Implémentez `balanceOf` pour renvoyer le nombre de zombies qu'un `_owner` a.
 

fr/5/04-erc721-4.md

@@ -332,15 +332,15 @@ material:
       }
 ---
 
-Oups ! Nous venons juste de rajouter une erreur dans notre code qui l’empêche de compiler. Est-ce que vous l'avez vu ?
+Oups ! Nous venons juste de rajouter une erreur dans notre code qui l’empêche de compiler. Est-ce que vous l'avez vue ?
 
 Dans le chapitre précédent, nous avons défini une fonction `ownerOf`. Mais si vous vous rappelez la Leçon 4, nous avons aussi créé un `modifier` avec le même nom, `ownerOf`, dans `zombiefeeding.sol`.
 
 Si vous essayez de compiler ce code, le compilateur va renvoyer une erreur vous disant qu'il ne peut pas y avoir un modificateur et une fonction avec le même nom.
 
 Pourrions-nous simplement changer le nom de la fonction dans `ZombieOwnership` en quelque chose d'autre ?
 
-Non, nous ne pouvons pas faire ça !!! Rappelez-vous, nous utilisons le standard de token ERC721, ce qui veut dire que d'autres contrats vont s'attendre que notre contrat ai les mêmes fonctions avec exactement les mêmes noms. C'est pour cela que ces standards sont utiles - si un autre contrat sait que notre contrat est conforme au standard ERC721, il peut simplement communiquer avec nous sans rien savoir de nos décisions d'implémentation interne.
+Non, nous ne pouvons pas faire ça !!! Rappelez-vous, nous utilisons le standard de token ERC721, ce qui veut dire que d'autres contrats vont s'attendre à ce que notre contrat ait les mêmes fonctions avec exactement les mêmes noms. C'est pour cela que ces standards sont utiles - si un autre contrat sait que notre contrat est conforme au standard ERC721, il peut simplement communiquer avec nous sans rien savoir de nos décisions d'implémentation interne.
 
 Ce qui veut dire que nous allons devoir réorganiser notre code de la Leçon 4 pour changer le nom du `modifier` en quelque chose d'autre.
 

fr/5/05-erc721-5.md

@@ -319,11 +319,11 @@ function approve(address _to, uint256 _tokenId) public;
 function takeOwnership(uint256 _tokenId) public;
 ```
 
-1. La première façon est que le propriétaire du token appelle `transfer` (transférer) avec l'`address` de destination, and le `_tokenId` du token qu'il veut transférer.
+1. La première façon est que le propriétaire du token appelle `transfer` (transférer) avec l'`address` de destination, et le `_tokenId` du token qu'il veut transférer.
 
-2. La deuxième façon est que le propriétaire appelle d'abord `approve`, et lui envois les même infos que ci-dessus. Le contrat va stocker qui a été approuvé à prendre le token, souvent dans un `mapping (uint256 => address)`. Ensuite quand quelqu'un va appeler `takeOwnership`, le contrat va vérifier que `msg.sender` a été approuvé par le propriétaire pour prendre le token, et si c'est le cas, il va lui transférer le token.
+2. La deuxième façon est que le propriétaire appelle d'abord `approve`, et lui envoit les mêmes informations que ci-dessus. Le contrat va stocker qui a été approuvé à prendre un token, souvent dans un `mapping (uint256 => address)`. Ensuite quand quelqu'un va appeler `takeOwnership`, le contrat va vérifier que `msg.sender` a été approuvé par le propriétaire pour prendre le token, et si c'est le cas, il va lui transférer le token.
 
-Vous remarquerez que `transfer` et `takeOwnership` contienne la même logique de transfert, seulement en ordre inverse. (Dans un cas, c'est l'expéditeur du token qui appelle la fonction, dans l'autre c'est le destinataire du token qui l'appelle).
+Vous remarquerez que `transfer` et `takeOwnership` contiennent la même logique de transfert, seulement en ordre inverse. (Dans un cas, c'est l'expéditeur du token qui appelle la fonction, dans l'autre c'est le destinataire du token qui l'appelle).
 
 C'est donc logique de mettre cette logique dans sa propre fonction privée, `_transfer`, qui sera appelée par chacune des fonctions. De cette manière nous n'avons pas à réécrire le code deux fois.
 

fr/5/06-erc721-6.md

@@ -318,7 +318,7 @@ Bien ! C'était la partie difficile — maintenant implémenter la fonction publ
 
 ## A votre tour
 
-1. Nous voulons être sûr que seulement le propriétaire du token/zombie puisse le transférer. Vous vous rappelez comment limiter l'accès à un fonction à seulement son propriétaire ?
+1. Nous voulons être sûrs que seulement le propriétaire du token/zombie puisse le transférer. Vous vous rappelez comment limiter l'accès à une fonction à seulement son propriétaire ?
 
    Oui, c'est ça, nous avons déjà un modificateur qui fait ça. Ajoutez donc le modificateur `onlyOwnerOf` à cette fonction.
 

fr/5/07-erc721-7.md

@@ -327,15 +327,15 @@ Rappelez-vous, avec `approve` / `takeOwnership`, le transfert se fait en 2 étap
 
 2. Le nouveau propriétaire appelle `takeOwnership` avec le `_tokenId`, le contrat vérifie que cela a bien été approuvé, et lui transfère le token.
 
-Vu que cela se passe en 2 appels de fonction, nous avons besoin d'une structure de donnée où stocker qui a approuvé quoi entre l'appel des fonctions.
+Vu que cela se passe en 2 appels de fonction, nous avons besoin d'une structure de données où stocker qui a approuvé quoi entre les appels des fonctions.
 
 ## A votre tour
 
 1. Premièrement, définissez un mappage `zombieApprovals`. Cela devra associer un `uint` à une `address`.
 
   De cette manière, quand quelqu'un appelle `takeOwnership` avec un `_tokenId`, nous pourrons utiliser ce mappage pour rapidement voir qui est approuvé à prendre ce token.
 
-2. Dans la fonction `approve`, nous voulons être sûr que seulement le propriétaire du token puisse donner à quelqu'un l'autorisation de le prendre. Nous devons donc ajouter le modificateur `onlyOwnerOf` à `approve`.
+2. Dans la fonction `approve`, nous voulons être sûrs que seulement le propriétaire du token puisse donner à quelqu'un l'autorisation de le prendre. Nous devons donc ajouter le modificateur `onlyOwnerOf` à `approve`.
 
 3. Pour le corps de la fonction, définissez `zombieApprovals` pour `_tokenId` égal à l’adresse `_to`.
 

fr/5/08-erc721-8.md

@@ -337,4 +337,4 @@ La dernière fonction, `takeOwnership`, devra simplement vérifier que `msg.send
 
 3. Enfin, appelez `_transfer`, et passez lui tous les arguments nécessaires. (Vous pouvez ici utiliser `msg.sender` pour `_to`, vu que la personne qui appelle la fonction est celle à qui le token devra être envoyé).
 
-> Remarque : Nous aurions pu écrire l'étape 2 et 3 en une seule ligne de code, mais c'est plus clair de séparer les choses. Préférence personnelle.
+> Remarque : Nous aurions pu écrire les étapes 2 et 3 en une seule ligne de code, mais c'est plus clair de séparer les choses. Préférence personnelle.

fr/5/09-safemath-1.md

@@ -386,9 +386,9 @@ material:
 
 Félicitations, cela complète notre implémentation ERC721 !
 
-Ce n'était pas si dur que ça, n'est-ce pas ? Beaucoup de chose en Ethereum paraissent compliquées quand on en entend parler, et la meilleure façon de le comprendre et de faire l'implémenter soi-même.
+Ce n'était pas si dur que ça, n'est-ce pas ? Beaucoup de choses en Ethereum paraissent compliquées quand on en entend parler, et la meilleure façon de le comprendre est d'en faire l'implémentation soi-même.
 
-Garder en tête que c'était une implémentation minimale. Il y a d'autres fonctionnalités que nous voudrions ajouter à notre implémentation, comme s'assurer que les utilisateurs ne transfèrent pas accidentellement leurs zombies à l'adresse `0` (on appelle ça brûler un token - l'envoyer à une adresse dont personne n'a la clé privée, le rendant irrécupérable). Ou rajouter une logique d'enchère sur notre DApp. (Est-ce que vous voyez une façon de faire ça ?)
+Gardez en tête que c'était une implémentation minimale. Il y a d'autres fonctionnalités que nous voudrions ajouter à notre implémentation, comme s'assurer que les utilisateurs ne transfèrent pas accidentellement leurs zombies à l'adresse `0` (on appelle ça brûler un token - l'envoyer à une adresse dont personne n'a la clé privée, le rendant irrécupérable). Ou rajouter une logique d'enchère sur notre DApp. (Est-ce que vous voyez une façon de faire ça ?)
 
 Mais nous voulons garder cette leçon simple, nous avons opté pour l'implémentation la plus basique. Si vous voulez voir un exemple d'une implémentation plus détaillée, vous pouvez regarder le contrat ERC721 d'OpenZeppelin après ce tutoriel.
 
@@ -411,17 +411,17 @@ Dans ce cas, nous avons causé un débordement par le haut - `number` est contre
 
 Un débordement par le bas est similaire, si vous soustrayez `1` d'un `uint8` égal `0`, le résultat sera `255` (car les `uint` sont non signés et ne peuvent pas être négatifs).
 
-Nous n'utilisons pas de `uint8` ici, et il paraît peut probable qu'un `uint256` débordera avec des incrémentations de `1` par `1` (2^256 est un nombre très grand), mais c'est toujours bon de protéger notre contrat afin que notre DApp n'est pas des comportements inattendus dans le futur.
+Nous n'utilisons pas de `uint8` ici, et il paraît peut probable qu'un `uint256` débordera avec des incrémentations de `1` par `1` (2^256 est un nombre très grand), mais c'est toujours bon de protéger notre contrat afin que notre DApp n'ait pas de comportements inattendus dans le futur.
 
 ### Utiliser SafeMath
 
 Pour prévenir cela, OpenZeppelin a créé une **_bibliothèque_** appelée SafeMath qui empêche ces problèmes.
 
 Mais d'abord, c'est quoi une bibliothèque ?
 
-Une **_bibliothèque_** est un type de contrat spécial en Solidity. Une de leurs fonctionnalités est que cela permet de rajouter des fonctions à un type de donnée native.
+Une **_bibliothèque_** est un type de contrat spécial en Solidity. Une de leurs fonctionnalités est que cela permet de rajouter des fonctions à un type de données natif.
 
-Par exemple. avec la bibliothèque SafeMath, nous allons utiliser la syntaxe `using SafeMath for uint256`. La bibliothèque SafeMath à 4 fonctions — `add`, `sub`, `mul`, et `div`. Et maintenant nous pouvons utiliser ces fonctions à partir d'un `uint256` en faisant :
+Par exemple. avec la bibliothèque SafeMath, nous allons utiliser la syntaxe `using SafeMath for uint256`. La bibliothèque SafeMath a 4 fonctions — `add`, `sub`, `mul`, et `div`. Et maintenant nous pouvons utiliser ces fonctions à partir d'un `uint256` en faisant :
 
 ```
 using SafeMath for uint256;

fr/5/11-safemath-3.md

@@ -494,7 +494,7 @@ Cela veut dire que nous allons devoir implémenter 2 bibliothèques de plus pour
 
 Le code sera exactement le même que SafeMath, à l'exception des instances `uint256` qui seront remplacées par `uint32` ou `uint16`.
 
-Nous avons pris de l'avant et avons implémenté ce code pour vous — vous pouvez voir le code dans `safemath.sol`.
+Nous avons pris de l'avance et avons implémenté ce code pour vous — vous pouvez voir le code dans `safemath.sol`.
 
 Maintenant nous devons l'implémenter dans ZombieFactory.